Generation and control of network events and conversion to scada protocol data types.

(54) Title: GENERATION AND CONTROL OF NETWORK EVENTS AND CONVERSION TO DATA TYPES OF DATA ACQUISITION PROTOCOL AND SUPERVISION CONTROL.

(54) Tltle: GENERATION AND CONTROL OF NETWORK EVENTS AND CONVERSION TO SCADA PROTOCOL DATA TYPES.

(57) Summary

A system and method is described for receiving a network event in a network format, for mapping the network event in a format expected by a central monitoring system, and for communicating the mapped network event to the central system. monitoring. The system could employ a variety of communication protocols and physical architectures. The system could include an access controller that could be connected to a plurality of intelligent electronic devices and could be the primary interface with an information system or central monitoring system. The access controller could include a programmable logic motor in accordance with the IEC-61131-3 standard. The access controller could also be configured to implement the rules designed to govern the actions taken as a result of the network information.

(57) Abstract

A system and method¡s disclosed for receiving a network event in the network format, mapping the network event into a format expected by a central monitoring system, and communicating the mapped network event to the central monitoring system. The system may employ a variety of communication protocols and physical architectures. The system may include an access controller that may connect a plurality of intelligent electronic devices and may be the primary interface with an Information system or central monitoring system. The access controller may inelude a programmable logic engine in compliance with the IEC-61131 -3 standard. The access controller may further be configured to implement rules designed to govern actions taken as a result of network Information.

GENERATION AND CONTROL OF NETWORK EVENTS AND CONVERSION TO TYPES

DATA PROTOCOL FOR DATA ACQUISITION AND CONTROL OF

SUPERVISION

Field of the Invention

This description refers to the communication, generation and control of operation and network events within an automatic, control, monitoring or protection system. More particularly, this description refers to a method and apparatus with the ability to generate and control network events and convert network events into a protocol used by a central monitoring system, such as Data Acquisition and Supervision Control (SCADA), interruption management systems, Automatic Meter Reading (AMR) systems,

Advanced Measurement Infrastructure (AMI), and the like.

Brief Description of the Figures

The additional aspects and advantages will be apparent from the following detailed description of the preferred modalities, which continues with reference to the accompanying figures, where:

Figure 1 illustrates an automation, control, monitoring and / or protection system for various pieces of monitored equipment;

Figure 2 illustrates a diagram of a

REF. 214124 automation, control, monitoring or protection in connection with an architecture of an electric power system;

Figure 3 is a block diagram illustrating a network event mapping system to SCADA protocol data types;

Figure 4 is a flowchart showing a process for mapping network events to SCADA protocol data types;

Figure 5 is a block diagram of a process for mapping network events to protocol data types.

SCADA in an access controller;

Figure 6 is a block diagram illustrating a programmable rules module within an access controller; and

Figure 7 is a flow diagram illustrating the process of mapping a network event to a SCADA system.

Detailed description of the invention

Typically, modern electrical energy transmission, distribution, and automation systems include intelligent electronic devices (IEDs) for the protection, control, automation, and / or monitoring of equipment in the system. IEDs could be used to monitor equipment of many types including electric transmission lines, current transformers, pumps, compressors, valves, etc.

Generally, an IED could refer to a microprocessor-based device that monitors, controls, automates, and / or protects the monitored equipment within the system. These devices could include, for example, remote terminal units, differential relays or relays, distance relays, directional relays, power relays, overload relays, voltage regulator controls, voltage relays, breakdown fault relays, relays generator, motor relays, automation controllers, bay controllers, gauges, reconnect controllers, communications processors, computing platforms, programmable logic controllers (PLCs), programmable automation controllers, input and output modules, motor drivers, and the like. IEDs collect the status information of one or more pieces of monitored equipment, and could control various aspects in relation to the monitored equipment. IEDs could receive information regarding the monitored equipment using sensors, transducers, actuators, and the like.

IEDs could be configured to transmit the collected or collected information about the monitored equipment to a central monitoring system such as the systems

SCADA, ARM and AMI. IEDs could be configured to communicate information, such as voltages, currents, equipment status, temperature, frequency, pressure, density, infrared absorption, radio frequency information, partial pressures, viscosity, speed, rotational speed, mass, switch state , valve status, circuit breaker status, connection status, meter readings, and the like. IEDs could also be configured to communicate calculations, such as current vectors (which may or may not be synchronized as synchronization current vectors), events, fault distances, differentials, impedances, reactances, frequency, and the like. The IEDs could also communicate the setting information, the IED identification information, the communication information, the status information, the alarm information, and the like. Information about the types listed above, or more generally, information about the status of the monitored equipment is referred to as the monitored system data.

IEDs could also issue or send control instructions to the monitored equipment. For example, an IED could be in communication with a circuit breaker, and might be able to send a command to open and / or close the circuit breaker, thereby connecting or disconnecting a portion of a electric power. The IED may also be able to make load restriction decisions. In another example, an IED could be in communication with a connection resetter and be able to command reconnect operations. In another example, an IED could be in communication with a voltage regulator and be able to command the voltage regulator to connect and / or disconnect. Other examples of control instructions that could be implemented using IEDs, might be known to a person skilled in the art, although not listed here. The information of the types listed above, or more generally, the information or instructions that are directed to an IED or other device to perform a certain action, is referred to as the control instructions.

IEDs could be linked together using a data communications network, and could also be linked to a central monitoring system or an information system. The data communications network could include a variety of network technologies, and could comprise network devices such as modems, routers, firewalls, virtual private network servers, and the like. IEDs and other network devices are connected to the communications network through a network interface module (NIM).

IEDs could be configured to communicate with a central IED, which could also be the primary interface to an information system or central monitoring system. A central IED could be, for example, the SEL2020, SEL-2030, SEL-2032, or SEL-3332, available from Schweitzer Engineering Laboratories, Inc., of Pullman, WA, and also as described in the US Patent. United

No. 5,680,324, the entirety of which is incorporated herein by reference. IEDs communicate information to the central IED that includes, but is not limited to, status and control information about individual IEDs, IED adjustment information, calculations made by individual IEDs, event (failure) reports , communications network information, network security events, and the like. Central IEDs, or communications processors, could be cascaded in order to increase the number of connections to pieces of monitored equipment. An access controller, as described in detail below, could serve as a central IED or a communications processor.

The physical architecture of the data communication network connecting the IEDs and other network devices could be any known to a person skilled in the art, and could include fiber optic contact inputs and outputs, Ethernet, and the like. . IEDs could follow any of a number of different protocols in communication with an access controller as described below. All IEDs could communicate using the same protocol, or they could communicate through different protocols with the access controller. Some available communication protocols include, for example, Mirrored Bits® from Schweitzer Engineering Laboratories, (described in United States Patent Nos. 5, 793,750, 6, 947,269 and in

United States Patent Application No. 2005/0280965, all assigned to the signer of this patent application, and all of which are incorporated herein by reference), the Distributed Rapid Message Network Protocol of Schweitzer Engineering Laboratories, (DNP) 3.0 Serial, DNP 3.0 LAN / WAN, MODBUS RTU, MODBUS TCP, IEC

61850, IEEE C37.118, and the like. Central monitoring systems could use these same protocols or formats in the same way to communicate with individual IEDs or central IEDs.

Individual IEDs, central IEDs, or other network devices may allow users to register the device to perform such actions as setting changes, system updates, test conduction, information gathering, and performing other functions. Some devices may allow the user to log in remotely from another location using the communications network. Similarly, other devices connected to the data communications network could allow users to log in and perform a variety of tasks.

Improper changes to an IED or other data communications network device could cause a disruption to the monitored system. Consequently, IEDs and other network devices could employ various techniques to ensure that only authorized users are allowed access. IEDs and other network devices could employ various systems to authenticate the user before allowing access to a device or allowing a user to change the settings. At a minimum, a password is normally required in order to register with an IED or other network device. Other authentication methods, for example biometric authentication, could also be used.

IEDs and other network devices may record network related events or statistics, such as user logins, user logoffs, failure logins, setting changes, updates, tests, repeated attempts password, network diagnostics, unidentified attempts to access. through restricted Internet protocol ports, firewall access, packet size, packet timeout, and the like. Information of the types listed above, or more generally, information in relation to events or statistics that refer to the data communications network that connects IEDs and other network devices, is referred to as network data. or a network event.

Typically, network data is transmitted or made available only to an information system. Generally, the information system includes network communication, network security, user administration, Internet and intranet administration, remote network access, and the like. The information system uses information about the network to maintain and sustain a reliable, quality, and secure communications network by running business logic in real time based on network security events, by performing network diagnostics , optimize network performance, and the like. Network events could be automatically pushed to the information system, or they could be contained in registers that are accessible depending on the request to the information system.

Historically, the monitored system information has been transmitted to central monitoring systems, such as a SCADA system. Due to network security and operation concerns, information is typically not shared between central monitoring systems and the information system. The division between the central monitoring systems and the information system could have been beneficial from the point of view of network security because the risk of unauthorized access to the SCADA system is reduced; however, certain information that is typically communicated only to the information system may also be useful to operators of a central monitoring system. Communication of network data to the SCADA control center, for example, could be advantageous because SCADA control centers could be under-staffed on an ongoing basis, and SCADA information could be reviewed frequently almost on time. real. Automating the supply of network events to SCADA could provide

- additional protection that guarantees that only authorized users have access to the communications network. Furthermore, centralizing information related to both monitored system data and network data could simplify the procedures required to comply with corporate and government regulations.

Network events that could be of use to a central monitoring system operator include user logins, user session ends, setting changes, invalid password attempts, network diagnostics, Unidentified attempts to access through restricted Internet protocol ports, firewall access, packet size, packet timeout, and the like. This data is useful, so that the people or systems that monitor the system know who is starting and ending a session of each network device, what settings are being changed, if login attempts have failed, and the like . Providing operators with the central access monitoring system for network events could also help ensure that the correct settings are being applied to each device as changes are made. Access to network information is also useful in post-event analysis and security analysis that may be required - by government or corporate regulations. These advantages could not have been historically realized due to the security and operational problems discussed previously, and because the protocols used to transmit network data to the information system could not be compatible with the infrastructure and the protocols used by the central monitoring systems.

The systems and methods in this description allow the mapping of network events to any number of protocols using the existing infrastructure. As such, the benefits discussed above could be realized without significant changes to the existing infrastructure.

Next, with reference to Figure 1, an example protection, control, automatic and / or monitoring system 100 is represented. Figure 1 shows various pieces of monitored equipment in communication with various IEDs. For example, an electrical power conductor 160 is monitored by two IEDs 182 and 184. IEDs 182 and 184 could monitor the voltage, current, impedance, reactance, phase, or frequency associated with electrical power conductor 160. . IED 186 is shown to receive information from pump 170. IED 186 could monitor pressure, temperature, rotational speed of the shaft, flow rate, and / or status of the pump (for example, on / off ), and the like. IED 188 is illustrated monitoring a compressor 172. IED 188 could receive information about conditions in the compressor from the sensors in the compressor or the status of the compressor itself. In addition, IEDs 190-198 are illustrated, each of which is in communication with a sensor or other equipment placed in flow system 166 through which fluid may be traveling. Various sensors and equipment could be placed in flow system 166, such as valve 168, flow meter 180, IR absorption sensor 178, a pressure transducer 176, and a temperature transducer 174. Each sensor or equipment could be monitored through an IED 190, 198. Alternatively, several of the sensors or several separate pieces of equipment could be monitored through a single IED.

All IEDs 182-198 are in communication with an access controller 150. The access controller

150 it could be configured to receive information about various IEDs and communicate the information to a central monitoring system, such as a SCADA system 128, and to information system 126. Access controller 150 could also be in communication with a second controller Access 152 in a cascade configuration. The cascade setting allows the access controller

152 Receive information on additional IEDs.

Access controller 150 could also be in communication with a local human-machine interface (HMI) 124. Local HMI 124 could be located in the same substation as access controller 150. Local HMI 124 could be used to observe data from access controller 150 and / or initiate communications with access controller 150 to change settings, send control instructions, retrieve an event (failure) report, retrieve data , and the like.

The common time source 122 could be available to the access controller 150 to provide a common time to the access controller 150 and the connected IEDs. The common time source 122 could be used by the access controller 150 for the timestamp information and data. Time synchronization could be useful for data organization, real-time decision making, as well as post event analysis. Time synchronization could also be applied to network communications. The common time source 122 could be any time source that is an acceptable form of time synchronization. For example, the common time source 122 that could be available from GPS satellites and follows the IRIG-B protocol, could be provided through WWB or WWVB radio networks, or could be maintained locally through the access controller 150. Time could be synchronized across the entire system using a SCADA protocol (such as DNP 3.0 or IEC 61850), or using network time synchronization (such as Network Time Protocol or Simple Network Time Protocol) . In the absence of a common discrete time source, access controller 150 could serve as the time source by distributing a time synchronization signal (received from one of the described sources).

As illustrated in Figure 1, communication between SCADA system 128, information system 126, and IEDs is directed through access controller 150. Communications centralization using access controller 150 could provide the Ability to handle a wide variety of IEDs in a consistent way. As described in greater detail below, access controller 150 might be able to communicate with IEDs of various types and using various communications protocols. Access controller 150 could provide a common management interface for managing all connected IEDs, thereby allowing greater uniformity and making administration easier for dealing with a wide variety of equipment.

Communications centralization using access controller 150 could also allow for enhanced security. Access controller 150 could incorporate various security features, such as an authentication system, a firewall, a VPN server, and other security features. The routing of all communications through the access controller

150 it allows devices connected to access controller 150 to take advantage of these security features, rather than requiring multiple security devices to be connected to each IED or piece of monitored equipment. This configuration also reduces the possible area of ​​attack by unauthorized users. As discussed previously, Access Controller 150 could allow communication with IEDs operating on any number of protocols, including legacy devices that could not, to date, natively include security features and protocols. The use of access controller 150 could allow these legacy devices to remain in service and benefit from the secure environment created by access controller 150.

The connection between the access controller 150 and the SCADA 128 system and the information system 126 could be a single connection that is capable of simultaneously supporting the protocol and bandwidth requirements of the SCADA 128 system and the information 126. Figure 3 shows different connections for the SCADA system

128 and the information system 126; however, different connections do not require two physically different connections. A fiber optic or Ethernet connection, for example, could allow a single physical connection between access controller 150 and SCADA system 128 and information system 126.

In an embodiment illustrated in Figure 2, access controller 150 is used in a power system architecture 200. Access controller 150 is in communication with IEDs 102-120, a second access controller 152 in a configuration cascade, common time source 122, a local HMI 124, information system 126, and SCADA system 128.

IEDs 102-120 receive information from the power system that comes from electric power system 160. IEDs 102, 120 could receive information from the power system from sensors or from monitored equipment in the power system or combinations thereof. The IEDs could be configured, individually, regarding the information that they are going to communicate to the access controller 150. For example, IEDs 102-120 could receive current waveforms from current transducers installed in conductors or within other equipment of the electrical power system. Similarly, IEDs 102-120 could receive voltage information from potential transducers installed in conductors or within other equipment of the electrical power system. Alternatively, IEDs 102-120 could receive the switch status information, directly, from the circuit breaker (open or closed). IEDs 102-120 could receive connection information from voltage regulators. Other types of information could be collected using IEDs that could be known to a person who has experience in the art, even though they are not listed here.

IEDs 102-120 could also perform calculations on the power system information. Depending on the type, configuration and settings of an individual IED, the calculations could be carried out in such a way that they generate control instructions. For example, an IED could be configured to perform calculations for over-current conditions, over-voltage conditions, out-of-balance conditions, excessive power swing conditions, and to generate appropriate control instructions that they direct towards each condition.

Figure 3 illustrates an embodiment for receiving, processing, and distributing information within access controller 150. IEDs 102-106 are in communication with access controller 150. Access controller 150 includes a logical engine (LE) 300 operating on a processor (314). The LE 300 could operate with any number of protocols, network communication media, settings, and the like. Similarly, processor 308 could operate using any number of processing relationships, architectures, and could be implemented using a general-purpose or application-specific processor.

In one modality, the LE 300 could operate in accordance with the International Electrotechnical Commission (IEC) standard 61131-3. The IEC 6113-3 standard defines two graphics language standards and two textual programming language standards for PLC programming. The languages ​​included in the IEC 6113-3 standard are graphical languages, such as the Ladder Diagram (LD) and the Function Block Diagram (FBD), as well as textual languages, such as Structured Text (ST), Instruction List (IL) and the Sequential Function Graph (SFC).

The monitored system data and the network data from the various IEDs and the access controller 150 are processed by the LE 300. The monitored system data is routed to the SCADA 302 data module. The network data is routed to the module SCADA data module 302. The SCADA data module 302 processes the data intended to be communicated to and from the SCADA system 128 towards the data points that correspond to the communication protocol used by SCADA. The SCADA 302 data module could move information from one protocol to another protocol. For example, if the SCADA 128 system expects the data to be organized according to the MOBDUS TCP protocol, and the IED 102 communicates the data using the Schweitzer Engineering Laboratories Quick Message protocol, the SCADA data module 302 will move the data to the MOBDUS TCP protocol. The SCADA data module 302 could then form data packets according to the expected SCADA protocol and could transmit the data packets to the SCADA system 128 using the communication interface

SCADA 310.

The network data received from IEDs 102106 or generated through access controller 150 is processed by network data module 304. Network data module 304 processes the data intended for information system 126 towards the format or protocol expected by the information system 126. For example, if information system 126 waits for communication according to the TCP / IP protocol, network data module 304 will direct the data intended for information system 126 toward the TCP / IP protocol. The network data module 304 could then form data packets in accordance with the expected network protocol and could transmit the data packets to the information system 126 using the communication interface of communication system 312.

The LE 300 also includes a data mapping module

306 configured to map data from network data module 304 to SCADA data module 302. As described above, it might be desirable to communicate network data that is normally only communicated in information system 126 to SCADA system 128. The terms¹ which determine which network events are sent to the data mapping module 306 can be selected based on the importance of the operation. For example, network data module 3 04 could be configured not to transmit routine data network events (i.e., successful user registration) to data mapping module 306 because these events are not importance of operation. On the other hand, the network data module 304 could be configured to transmit repeated failure attempts for registration in the data mapping module 3 06 because this activity could indicate that an unauthorized user is trying to access the system . In this way, only network events and data that are important to the SCADA 128 system are received for monitoring and operations will be mapped to the SCADA 302 data module. The conditions for the selection of which events will be mapped could be based on the programmable logic in the

LE 300.

Access controller 150 could include a storage medium capable of being read by computer 308. The storage medium. Computer readable storage 308 could serve a variety of functions, such as keeping a record of monitored system data and network data. The log could include timestamps indicating the time of receipt of each piece of data and could serve as a backup site for the data transmitted to the SCADA system 128 and the information system 126. The storage medium capable of being read by computer 308 could also be the receiver of software modules or other susceptible instructions. be read by computer that are used by the access controller 150. The computer readable storage medium 308 could be any type of computer readable storage medium, including but not limited to a hard drive or flash memory. Computer readable storage medium 308 could be accessible through SCADA system 128 (connection not shown), through information system 126 (connection not shown, or through local HMI 124 (connection not shown).

Figure 4 illustrates a process 400 performed through an access controller 150 mode in receiving a network event, mapping the event to a format expected by a SCADA system, and transmitting the mapped network event to the system. SCADA. In step 402, network data or monitored system data is received. In step 404, the monitored system data is routed to the SCADA data module 302, while the network data is routed to the network data module 304.

In step 406, the network data module determines whether the network data is of a type that will be transmitted to a SCADA system. As previously discussed, only certain network data could be of interest to SCADA operators. If the network data is of the type that is transmitted to the SCADA, the network data is also routed to the data mapping module 306 and the process continues at step 416.

All network data continues from step 406 to step 408, where network data module 304 determines whether the received data is in the format expected by the information system. If the data is not in the expected format, the data is transferred in step 410. In step 412, the data is in the expected format, and a network data packet is created. In step 412, a packet data header could be created that includes the routing information indicating the source and destination of the packet, the length of the packet, and the error verification or error correction information. The network data packet is transmitted to the information system in step 414.

In step 416, the network data is mapped into a format expected by SCADA. As discussed herein, the data could be mapped to a variety of formats. The mapped data format could be any data format used by the SCADA system. In step 416, a data type conversion (i.e., the conversion to an analog data type) could be performed if necessary.

In step 418, the SCADA data module 302 determines whether the monitored system data is in the format expected by the SCADA system. If the data is not in the expected format, the data is transferred in step 420. The translation performed in steps 420 and 410 could allow the use of any number of different protocols, thus allowing the use of devices that could communicate with the access controller 150 using different protocols.

In step 422, the data (including the moved data or the mapped network data) is in the format expected by the SCADA system, and the SCADA data packet is created. In the same way as with a network packet, the SCADA data packet could include a header that contains the routing information indicating the source and destination of the packet, the length of the packet, and the error verification or correction information. error. The SCADA data packet is transmitted to the system

SCADA at step 424.

Figure 5 illustrates a block diagram of the data mapping process that occurs within LE 300. Figure 5 illustrates how the network events of the access controller and its connected IEDs could be communicated to SCADA using existing SCADA protocols. Specifically, Figure 5 illustrates the mapping of network data 504 to the DNP data packet. Network data 504 passes through network data module 304. The network data module 304 passes the data to the data mapping module 306, which creates the mapped network data for use through the SCADA data module 302.

Figure 5 further illustrates mapping the monitored data from system 502 to a DNP data table. Data mapping module 306 maps network data 504 and monitored system data 502 to the DNP packet. The DNP packet could be restricted to contain either the data from the 304 network data module or the power system data, or as shown, the DNP packet could contain both the network data and the monitored system data.

The SCADA data module formats the DNP packet for transmission to the SCADA 128 system. The DNP box includes a header section 506 (which includes the synchronization, length, link control, destination address, source address and redundancy check) and a data section 508. The data points associated with the network data 504 are mapped to the data section 508 of the DNP table. The DNP_Point_3 and DNP_Point_4 data points are mapped using the Structured Text programming language provided by the IEC 61131-3 standard on network events that represent a user login and logout. In this example, the DNP_Point_3 and DNP_Point_4 data points are analog DNP data types. The DNP_Point_3 data point is associated with a user logon network event and the DNP_Point_4 data point is a user logout network event. In this case, data mapping module 306 will populate data point DNP_Point_3 with an integer suitable for user login to the system. Similarly, it will populate the DNP_Point_4 data point with an integer suitable for system user session termination. In this example, the integer that will be used by each user can be configured within the data mapping module 306. A data type conversion may or may not be necessary depending on the network event data.

Figure 6 illustrates a block diagram of an access controller 600 that also includes a rule module 602 that operates within LE 603. The rule module

602 It could be used to implement rules that govern the actions that will be taken in response to network data or SCADA data monitored by access controller 600.

Rule module 602 could be used to generate and control network and user access rules using rule module 602. One benefit of rule module 602 is that actions could be taken to prevent unwanted access more quicker than simply monitoring the data received by the SCADA system. Implementing the rules using rule module 602 avoids the inevitable communication delays and / or human interaction timeouts that could be incurred by transmitting data to the SCADA system

128 or the information system 126 and waiting for the intervention of an operator. The computer readable storage medium 308 could also store a record of the actions taken by rule module 602, and could also store various modules for storing, creating, modifying, and implementing various rules. Rules could be added to rule module 602 using a local HMI 124 or SCADA 128, and could be programmed in accordance with IED standard 61131-3.

Using rule module 602, the user could create rules that govern access to access controller 600 and / or IEDs based on certain network events and / or information from SCADA data module 302. For example, the module of rules 602 could implement rules to increase or decrease user access to access controller 600, an individual IED, and / or all

IEDs connected depending on certain conditions. Rules module 602 could be configured as a firewall (for example, a device that inspects traffic that passes through it, and denies or allows passage based on a set of rules). Rules module 602 could be configured to manage user account rules that govern access to access controller 600 or more

IEDs connected to the access controller 600. Rules module 602 could manage user account rules such as requiring users to change passwords after a specified duration of time or number of logins, granting varying levels of access to different users (for example , read-only access, read / write access), or automatically making certain types of data available when a particular user logs on.

The rules module 602 could also be configured to implement control instructions, automation actions and / or protection actions in conjunction with various IEDs. For example, when SCADA data meets the conditions defined by a rule, rule module 602 could issue a control instruction to an IED in communication with a circuit breaker to open and / or close the circuit breaker. In this way, a portion of the power system is connected or disconnected. In another example, rule module 602 could send or issue a control instruction to an IED in communication with a voltage regulator to connect and / or disconnect when the SCADA data meets the conditions defined by a rule.

Figure 7 illustrates the implementation of a rule

702 that governs the actions that will be performed in the event of three failure attempts to register in the access controller 600. In the example, once three consecutive failure attempts have been registered in the access controller 600, the module Rules 602 sends a control instruction causing access controller 600 to enter lockout or override mode. The process begins after the third failed login attempt, when the network interface module 704 generates a network event 700 indicating that the variable

User_Fail_Attemps equals 3. Network event 700 is reported to network data module 304. Network data module 304 is configured to alert the rule module

602 in the event of three failed user logins. The rules module 6 02 compares the input network event 700 with the rule 702. The test condition through the rule is true. Rule module 602 then sets the Network_Interface_Disabled and Lockout_Mode variables to a state of true. These variables cause access controller 600 to terminate communication using network interface module 704, thus, any type of possible threats proposed by network communication are disabled. Continuing the example, the rules module also sends a command to the IED 102 to take some protection action, such as entering the blocking mode, disconnecting the switch, closing a contact output or deactivating its network interface based on the functionality available on IED 102. So the gatekeeper

600 communicates the failure login network events and actions implemented by rule module 602 to both SCADA 128 and IS 126.

The modalities described herein could include several stages, which in turn could be included in computer-executable instructions stored in a computer-readable medium that will be executed by a general-purpose or special-use computer (or other Electronic device). For example, the access controller described above could be implemented using a programmable logic controller. The computer readable medium described herein could include, but is not limited to, hard drives, floppy disks, optical discs, CD-ROMs, DVD-ROMs, ROMs, RAMs, flash memory, EPROMs , EEPROMs, magnetic or optical cards, solid state memory devices, or other types of computer-readable media / media suitable for the storage of electronic instructions. Alternatively, the steps could be performed using hardware components that include specific logic for performing the steps, or by a combination of hardware, software, and / or firmware.

Various aspects of the described modalities have been illustrated as modules or software components. As used herein, a software module or component could include any type of computer instruction or computer executable code located within the memory device. A software module could comprise, for example, one or more physical or logical blocks of computer instructions, which could be organized as a routine, program, object, component, data structure, etc., that performs one or more tasks or that implements particular types of abstract data.

In certain embodiments, a particular software module could comprise different instructions stored in different locations on a memory device, which together implement the described functionality of the module. Instead, a module could comprise a single instruction or many instructions and could be distributed across several different code segments, between different programs, and across multiple memory devices. Some modalities could be practiced in a distributed computing environment where tasks are performed through a remote processing device linked through a communications network. In a distributed computing environment, the software modules could be located on local and / or remote memory storage devices. In addition, the data being joined or joined in a database record could be residing on the same memory device, or across multiple memory devices, and could be linked together on campus from a record in a database data over a network.

While the specific embodiments and applications of the disclosure have been illustrated and described, it will be understood that the disclosure is not limited to the precise configuration and components described herein. Various modifications, changes, and variations apparent to those of skill in the art could be made in the arrangement, operation, and details of the methods and systems of the description without departing from the spirit and scope of the description.

It is noted that in relation to this date, the best method known by the applicant to put the aforementioned invention into practice is the one that is clear from the present description of the invention.