TECHNICAL FIELD

[0001] This application relates to cybersecurity in operational technology (OT). More particularly, this application relates to monitoring programmable logic controllers using a connection-oriented network protocol.

BACKGROUND

[0002] A programmable logic controller (PLC) is a specialized computer control system configured to execute software which continuously gathers data on the state of input devices to control the state of output devices. A PLC typically includes three major components: a processor (which may include volatile memory), volatile memory comprising an application program, and one or more input/output (I/O) ports for connecting to field devices in the automation system. Field devices perform, for example, mechanical or electrical operations based on instructions from the PLC. Examples of field devices include valves, switches, sensors (e.g., temperature, pressure, and/or flow rate), and transmitters. The exact components included in a field device will depend upon its intended functionality.

[0003] Automated manufacturing and processing facilities are evermore threatened by cyberattacks, with PLCs being particularly vulnerable to various forms of interference including hijacking control of system components, altering states of devices, changing settings, falsifying sensor readings, etc. The detection of a manually or automatically triggered program termination, overwriting of the PLC program, communication interruption or hardware defect is usually detected in OT networks by means of invalid displays on an HMI (Human Machine Interface) or the absence of data updates in a SCADA (Supervisory Control and Data Acquisition) system. These technologies usually work by means of periodic queries or sending operational data to or from the PLC device.

[0004] In some cases, passive monitoring techniques are used that record administrative and operational data traffic, learn from it, and identify anomalies. Some of these solutions are also able to analyze protocols on deeper levels, but only for protocols that have been studied, often by reverse engineering the most popular OT device protocols, to understand the intricate context and structure of the various protocols. Typically, the passive monitoring device reads commands sent to and from a PLC device or other OT devices (e.g., “emergency stop” and “stop” commands for state of an inverter or driver). The passive monitoring device is programmed to interpret commands using an in-depth analysis for determining if an anomaly is present where the command is inconsistent with the expected state of an OT device. The disadvantage of these solutions is that the in-depth analysis requires inputs that are in plain text (not encrypted) to read the message content. With newer proprietary protocols in the OT environment now being encrypted, the conventional solutions cannot fully support monitoring of distributed control systems.

[0005] Furthermore, these techniques rely only on observing values, setpoints, function codes, and other information derived from the operation of the system. So, passive monitoring can only detect when a transmission contains anomalous data (i.e., information that does not match previously learned behavior). As such, malware attacks could be undetected. For example, an attacker may manage to infect an engineering computer used by a technician that updates the PLC program, and the malware modifies the PLC program to stop working after a delayed period. This update may not be visible to the passive monitoring if it is performed over a network that is not monitored, or also it could be whitelisted because there is maintenance work scheduled so the software update is expected. In this case, when the PLC stops performing its functions, the passive monitoring may not detect it (e.g., if an anomaly is not triggered at the network level).

SUMMARY

[0006] System and method are disclosed for monitoring programmable logic controllers (PLCs) for cybersecurity through leveraging a connection-oriented network protocol. A connection-oriented network protocol link is established between a background service and each of a plurality of PLCs. Each PLC generates a constant cyclical pulse signal having frequency set to align with scan cycles of a control program executed by the PLC. Process control modules of the control program are executed to control process facility field devices. The PLC sends a series of heartbeat messages on the link synchronized to the pulse signal, each heartbeat message containing a time value at which the heartbeat message occurs. The background service monitors the heartbeat messages from each PLC, detects potential cyberattack incident for PLC in response to any interruption of heartbeat messages from PLC, and sends an alert to upper control layer analysis unit to analyze cause for the interruption of heartbeat messages.

[0007] In other aspects, the background service detects a potential cyberattack incident for the PLC in response to the background service detecting a half-open communication link and sends an alert to an upper control layer analysis unit to analyze the cause for the half-open communication link. [0008] In other aspects, the background service detects a potential cyberattack incident for the PLC in response to the background service detecting a break in sequence numbers for a pair of consecutive heartbeat messages and sends an alert to an upper control layer analysis unit to analyze the cause for the break in sequence numbers.

BRIEF DESCRIPTION OF THE DRAWINGS

[0009] Non-limiting and non-exhaustive embodiments of the present embodiments are described with reference to the following FIGURES, wherein like reference numerals refer to like elements throughout the drawings unless otherwise specified.

[0010] FIG. 1 an example of an automation system environment in which embodiments of the present disclosure operate.

[0011] FIG. 2 shows an example of PLC scan cycles in accordance with embodiments of this disclosure.

[0012] FIG. 3 shows an example PLC control program operation in accordance with embodiments of this disclosure.

[0013] FIG. 4 shows an example of a PLC connection-oriented link for cybersecurity monitoring in accordance with embodiments of this disclosure.

[0014] FIG. 5 shows an example of handshaking for establishing a synchronized TCP communication link for heartbeat messages in accordance with embodiments of this disclosure. DETAILED DESCRIPTION

[0015] Herein, a "control program" of a programmable logic controller (PLC) refers to a software program developed by a system operator such as an automation engineer to solve a particular problem or perform a particular task (e.g., automatically operate a water pump based on inputs from sensors in an industrial process or production plant). The term "firmware" refers to an operating system deployed on the PLC by the PLC manufacturer and delivered to the system operator. The control program utilizes the capabilities of the firmware. Embodiments of this disclosure related to deployment of a heartbeat module may be either delivered by the manufacturer with the firmware, or may be delivered as a function block so that an automation engineer can drop the heartbeat module into the control program.

[0016] Methods and systems are disclosed to solve the technical problem of monitoring communications of PLCs in distributed control systems to detect potential cyber threats. Where conventional passive monitoring techniques fail to support cyber security for OT devices that operate with encrypted protocols, the disclosed embodiments provide a new messaging mechanism that does not rely on the content of the protocol messages, thereby eliminating the need for decoding encrypted protocol messages. Disclosed embodiments enable detection of when a device restarts, crashes, or stops functioning, regardless of whether it is due to a physical attack or a logical attack, such as an anomalous command sent over the network over an unencrypted protocol. The disclosed monitoring approach ensures that the PLC is in "Run" Mode and on the network without any anomalous interruptions. In the disclosed solution, a heartbeat module is deployed on the PLC (e.g., loaded as firmware) for transmitting a cyclic pulse message with a frequency that aligns with scan cycles of the control program for the PLC. The pulse messages are transmitted over an established connection-oriented network protocol link (e.g., transmission control protocol (TCP) communication). A central background service establishes a link with each PLC to read the pulse messages as a continuous monitoring function. The pulse message may be a simple digital pulse, or may also contain a time value, timestamp (e.g., UTC), or sequence number for timing analysis. In the event of a power down of the PLC or loss of communication link to connected input/output (I/O) devices of the OT network, the pulse message will cease, and the background service can interpret the cessation of the pulse that an incident has occurred and analysis for a potential cyber threat can immediately be initiated. For example, to overwrite the control program code of the PLC, a built-in safety mechanism of the PLC requires a stop state be triggered for the PLC, in which the PLC is no longer controlling the field devices and the automation production processing (e.g., factory floor operations) of devices under control of the PLC is halted. It is not possible for a PLC to be programmed or for PLC firmware update to occur while the PLC is in a non-stop operation. Thus, any attempt by a cyber attacker to overwrite the PLC can be detected by a determination that the PLC has moved to the stop state. Prompt detection is essential for optimum diagnosis and recovery. As such, the disclosed method and system provides a technical solution for improved OT cybersecurity using a novel PLC communication link that mirrors the start and stop state of the PLC, without having to read or interpret network messages for presence of a stop comment, or any other such indicator of PLC anomalies. The need to reverse engineer protocol messaging for various OT devices is also eliminated. [0017] FIG. 1 illustrates an example of an automation system environment in which embodiments of the present disclosure operate. A process facility 100 includes an automation system having one or more PLCs 121 coupled to numerous workstations 112 via, for example, an Ethernet connection or bus 115. The PLCs 121 are also coupled to devices or equipment within the process facility 100 via sets of communication lines or buses. For example, as shown in FIG. 1 , PLC 121 a is connected to communication lines 128. The communication lines or buses 128 may be, for example, wired connections, wireless connections, or a combination of wired and wireless connections. The PLCs 121 are capable of communicating with control elements, such as field devices 131 and function blocks within field devices distributed throughout the process facility 100 to perform one or more process control modules 119 of a control program, which may implement desired control of the process facility 100 or of one or more processes operating in the process facility 100. The workstations 112 may be used by one or more configuration engineers to design the process control modules 119 to be executed by the PLCs 121 and display routines to be executed by the workstations 112 or other computers, and to communicate with the PLCs 121 so as to download such process control modules 119 to the PLCs 121. The workstations 112 may execute display routines that receive and display information pertaining to the process facility 100 during operation of the process facility 100.

[0018] Each of the PLCs 121 includes a memory 122 that stores control and communication applications and a processor 124 that executes the control and communication applications in any known manner. Each of the PLCs 121 stores and executes a PLC application that implements a control strategy using a number of different, independently executed, control modules 119. The control modules 119 may each be made up of what are commonly referred to as function blocks wherein each function block is a part or a subroutine of an overall control routine and operates in conjunction with other function blocks (via communications called links) to implement process control loops within the process facility 100, e.g., to control the operation of one or more processes performed by the process facility 100.

[0019] Function blocks, which may be objects in an object oriented programming protocol, typically perform one of an input function, such as that associated with a field device such as a transmitter, a sensor or other process parameter measurement device; a control function, such as that associated with a control routine; or an output function which controls the operation of some device, such as a valve or other field device 131 , to perform some physical function within the process facility 100. Hybrid and other types of complex function blocks exist such as model predictive controllers (MPCs), optimizers, or the like. While the Fieldbus protocol (e.g., Profinet) use control modules and function blocks designed and implemented in an object oriented programming protocol, the control modules could be designed using any desired control programming scheme including, for example, sequential function chart or ladder logic, and are not limited to being designed using function block or any other particular programming technique.

[0020] The workstations 112 may provide a graphical depiction of the process control modules 119 within the PLCs 121 to a user via a display screen illustrating the control elements within the process control modules 119 and the manner in which these control elements are configured to provide control of the process facility 100. [0021] In the process facility 100 illustrated in FIG. 1 , PLC 121 a is communicatively connected via the bus 128 to various field devices 131 , such as sensors and actuators.

Other types of devices may be connected to and be controlled by the PLCs 121. For example, a PLC 121 may be connected to one or more input/output (I/O) devices (not shown) which, in turn, may be connected to one or more field devices 131 . An I/O device may be used by a PLC 121 to enable communications between the one or more field devices, the PLC 12, and/or the process control system. As such, the I/O device may also be a participant in the direct execution of a control algorithm or loop to control a process.

[0022] Additionally, other PLCs 121 may be connected within the facility 100 to control other devices or areas associated with the process facility 100 and the operation of such additional PLCs 121 may be coordinated with the operation of the PLC 121a in any desired manner. In an embodiment, the process facility 100 of FIG. 1 includes one or more nodes for wireless communications (not shown) within the process facility 100, such as access points, gateways between wireless and wired networks within the facility 100, gateways to other networks, repeaters, routers, etc. within or external to the facility 100. These nodes for wireless communications may be communicatively coupled (using a wired protocol, a wireless protocol, or a combination thereof) to PLCs 121 , workstations 112, field devices 131 , other wireless enabled nodes, and other databases or data storage devices.

[0023] Control programs installed on a PLC are typically executed cyclically. The scan cycle time refers to the period of time in which the system is expected to provide new results. The scan cycle time in control applications is configurable by the user and should not exceed the time it takes to execute the control program. The period of time between the end of program execution and the beginning of the next program cycle is called the idle time. FIG. 2 illustrates cycles of 1000 msec each where the execution time of the program is 70 msec and the idle time is 30 msec. Control programs read inputs from the sensors at the beginning of the cycle, process the data, and write the outputs to memory or actuators, as shown in FIG. 3. The scan cycle time is dependent on the execution time.

[0024] Background service (BS) 111 is a software server that can be deployed in a variety of implementations: (1) on site as a local server of the process facility 100, (2) embedded in an edge-based computing device, or (3) operating remotely as a cloudbased server. A specialized communication link 141 is established with each PLC 121 , 121a during cybersecurity monitoring as a mechanism to determine the active state for each PLC. In an embodiment, the connection-oriented network protocol for the link 141 is TCP. Using the connection-oriented network protocol, a handshake is established with sharing of sequence numbers to initiate the communication. For each link 141 with respective PLCs 121 , the BS 111 checks the sequence with each message. The BS 111 uses information source IP, source Port, and Protocol to distinguish messages from each respective PLC 121. Should there be a break in the sequence, the BS 111 can use this as an indication that a disconnection with the PLC has occurred. In an embodiment, the BS 111 reports a detected anomaly as an alarm. In another embodiment, the BS 111 feeds information to an upper control layer analysis unit, such as SCADA, to analyze the PLC interruption and diagnose the cause.

[0025] FIG. 4 shows an example of a PLC connection-oriented link for cybersecurity monitoring in accordance with embodiments of this disclosure. Each PLC 121 has installed a generic function module 419 or function block as an additional routine of the PLC control modules 119 shown in FIG. 1 , which establishes and maintains a permanently active link with a central background service BS 111 . In an embodiment, the functionality of heartbeat message 403 is coupled to an active runtime of the PLC and the generic function module 419 is embedded in the firmware of the PLC device 121 .

[0026] A periodic transmission, such as a heartbeat message 403, is sent to the BS 111 to maintain the logical connection. The heartbeat message 403 is synchronized to constant cyclical pulse signal 402, with the pulse frequency set to align with the scan cycle (e.g., 100 msec scan cycle shown in FIG. 2) so that every scan cycle can be accounted for in the event of any interruptions of PLC activity. Scan cycle durations for a PLC device 121 typically are between 100 msec and 500 msec, but other scan cycles may be defined. In an embodiment, the pulse 402 frequency may be adjusted by an adjustment factor of the scan cycle to conserve resources by reducing the number of heartbeat messages 403 for transmission to the BS 111 . As an example for a 200 msec scan cycle, the pulse 402 frequency may be adjusted such that heartbeat messages 403 occur every 400 msec (i.e. , adjustment factor = 2). The heartbeat message 403 provides a steady indication that the PLC scan cycles are operating without interruption, as an assurance that the integrity of the control program PLC 121 has not been compromised. Should BS 111 detect any interruption to the heartbeat message 403 from any PLC 121 , BS 111 determines that a potential cybersecurity incident has occurred, and BS 111 generates an alert to such an indication. The alert may be sent to an operator of the OT system at a user interface (e.g., HMI device), and/or to an upper layer control unit (e.g., SCADA) for further diagnostic analysis to investigate the cause for the interruption. [0027] In an embodiment, the connection-oriented heartbeat message 403 includes timing information, such as a time value or timestamp with date and time information to indicate when the heartbeat message 403 occurs. The format for the heartbeat message 403 depends on constraints of specifications for PLC 121 (e.g., time units of msec or sec). By tracking timestamps, an anomalous interruption can be detected by any interval between heartbeats being greater than the regular pulse frequency. In an aspect, BS111 may detect an indication of a potential cyberattack incident from a received packet empty of heartbeat message data. Timing information is useful on the process side for troubleshooting and forensics analysis. In addition, timing information is useful for identifying problems introduced by network latency. In an embodiment, tracking sequence numbers associated with the connection-oriented network protocol are used instead of, or in addition to timestamps for detecting interruption of heartbeat messages.

[0028] FIG. 5 shows an example of handshaking for establishing a synchronized TCP communication link for heartbeat messages in accordance with embodiments of this disclosure. An established TCP communication link involves message exchanges as shown between PLC 121 and BS 111 which include acknowledgments and sequence numbers to ensure that data is delivered to the application (i.e., the PLC program, or the BS server implementation) in the proper order. TCP utilizes a number of flags, or 1-bit Boolean fields, in its header to control the state of a connection. These flags include SYN (Synchronize) to initiates a connection, FIN (Final) to cleanly terminate a connection, and ACK (Acknowledge) to acknowledge received data. The client on either side of the TCP session maintains a 32-bit sequence number it uses to keep track of how much data it has sent. This sequence number is included on each transmitted packet and acknowledged by the opposite host as an acknowledgement number to inform the sending host that the transmitted data was received successfully. When a host initiates a TCP session, its initial sequence number is effectively random.

[0029] As shown in FIG. 5, PLC sequence number begins at 14 (message 511) and BS 111 sequence number begins at 73 (message 512). Protocol analyzers may display relative sequence and acknowledgement numbers in place of the actual values. These numbers are relative to the initial sequence number of that stream. The first message 511 from PLC 121 includes the SYN flag to establish the sequencing. BS 111 acknowledges the message with an ACK flag and the BS 111 sequence number in message 512, setting the ACK number to the PLC sequence number incremented by one. PLC 121 acknowledges the BS 111 ACK message with an ACK flag and ACK number equal to the BS 111 sequence number incremented by one in message 513.

[0030] Messages 514, 516 include heartbeat messages encapsulated as a data packet of the TCP message payload (e.g., 5 bytes) along with a PUSH bit. Acknowledgement message 515 includes ack sequence 21 to account for message 514 of length 6.

[0031] For the client PLC 121 to terminate a communication session, a tear-down process commences with PLC sending a packet with the FIN flag set in message 518, and the ACK number remains the same as in the prior packet. In message 519, BS 11 1 acknowledges the PLC request to terminate the connection by increasing the ACK number by one and setting its FIN flag in turn. At message 520, PLC sends a final sequence number and acknowledges the BS 111 FIN flag by incrementing the ACK number by one. In an embodiment, a termination after two heartbeat messages, such as in this example, may trigger a notification that an anomalous interruption has occurred and there may be a potential cyberattack incident. For example, a threshold can be set for a minimum number of heartbeats as a trigger for such a notification. In another embodiment, when the communication link 141 is interrupted without the tear-down FIN message sequence 518, 519, a notification is triggered to the BS 111 for a potential cyberattack incident. In some embodiments, the PLC 121 implements a communication termination using a RESET (RST) flag instead of the FIN tear down.

[0032] Returning to FIG. 4, if during operation the PLC control program should enter stop mode, either virtually or physically, the next heartbeat message 403 is canceled according to an instruction encoded in the generic function module 419. By way of example, a user may send a virtual stop command via a software application such as Siemens TIA Portal or Step7 so that the PLC operation can be placed into Stop mode when downloading a program or other functions. An example of a physical stop mode for the PLC is operation of a physical switch or key. In an aspect, the communication link 141 for heartbeat message 403 may also become disconnected according to an instruction encoded in the generic function module 419. This also applies if the PLC program is reprogrammed, because each reprogramming is preceded by a stop in the currently running program and thus the termination of the communication link 141.

[0033] An advantage of implementing TCP messaging for the connection-oriented network protocol is that upon any potential cyberattack incident with the PLC, a teardown of a TCP link 141 happens on the PLC side, and the BS 111 observes several frames of communication data and/or timestamps. Upon the PLC restarting a power cycle and reestablishing the connection-oriented communication channel (e.g., when supply voltage is restored or when the program is restarted), the BS 111 can rely one or more of such physical bases rather than having to identify message content that could alert an incident. This also allows the BS 111 to detect extremely short outages.

[0034] In an embodiment for TCP based heartbeat message 403, a half-open connection at the BS 111 on the communication link 141 can occur in response to a cyberattack incident or intrusion (e.g., removal of the network connection or supply voltage), or a successful attack on the PLC firmware. This occurs when the PLC 121 does not actively terminate the TCP link (e.g., by sending a message with the FIN flag set) because of a sudden interruption, which may be an operational error or a malicious cause such as a cyberattack incident. The BS 111 detects a half-open TCP connection by monitoring the sequence numbers of heartbeat 403 messages. In response to detecting a half-open communication link, BS 111 determines that a potential cybersecurity incident has occurred, and BS 111 generates an alert to such an indication. The alert may be sent to an operator of the OT system at a user interface (e.g., HMI device), and/or to an upper layer control unit (e.g., SCADA) for further diagnostic analysis to investigate the cause for the half-open connection.

[0035] The disclosed embodiments provide a technical solution to the failure of state of the art passive network monitoring technologies to detect interruption times of PLC programs or with a delayed detection of general lack of network activity. Furthermore, the detection by conventional passive network monitoring approaches is based on the analysis of the traffic data, the knowledge of proprietary protocol versions, and the firmware parameters of respective PLC devices. However, encryption of this network data, as used in the latest OT communication protocol standards (e.g., IEC 61850 having encryption features, or Distributed Network Protocol Secure Authentication (DNP3-SA)), renders this approach impractical. In contrast, using the proposed solution of the disclosed embodiments, there is no need for any prior knowledge of operational or administrative manufacturer-dependent traffic data.

[0036] In addition, only minimal resources are required to operate the heartbeat messages 403, and the proposed function module 419 is operated logically independent of the operative part of the control program modules 119.

[0037] Computer readable medium instructions for carrying out operations of the present disclosure may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C++ or the like, and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The computer readable program instructions may execute entirely on the computing device, partly on the computing device, as a stand-alone software package, partly on the computing device and partly on a remote computer or entirely on the computing device or server. In the latter scenario, the remote computer may be connected to the computing device through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects of the present disclosure.

[0038] Aspects of the present disclosure are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the disclosure. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, may be implemented by computer readable medium instructions.

[0039] The program modules, applications, computer-executable instructions, code, or the like depicted in FIG. 1 as being stored in the system memory 122 are merely illustrative and not exhaustive and that processing described as being supported by any particular module may alternatively be distributed across multiple modules or performed by a different module. In addition, various program module(s), script(s), plug-in(s), Application Programming Interface(s) (API(s)), or any other suitable computer-executable code hosted locally on the PLC 121 , and/or hosted on other computing device(s) accessible via one or more of network, may be provided to support functionality provided by the program modules, applications, or computer-executable code and/or additional or alternate functionality. Further, functionality may be modularized differently such that processing described as being supported collectively by the collection of program modules 119, 419 may be performed by a fewer or greater number of modules, or functionality described as being supported by any particular module may be supported, at least in part, by another module. In addition, program modules that support the functionality described herein may form part of one or more applications executable across any number of systems or devices in accordance with any suitable computing model such as, for example, a client-server model, a peer-to-peer model, and so forth. In addition, any of the functionality described as being supported by any of the program modules depicted in FIG. 1 may be implemented, at least partially, in hardware and/or firmware across any number of devices.

[0040] It should further be appreciated that the PLC 121 may include alternate and/or additional hardware, software, or firmware components beyond those described or depicted without departing from the scope of the disclosure. More particularly, it should be appreciated that software, firmware, or hardware components depicted as forming part of the PLC 121 are merely illustrative and that some components may not be present or additional components may be provided in various embodiments. While various illustrative program modules have been depicted and described as software modules stored in system memory 122, it should be appreciated that functionality described as being supported by the program modules may be enabled by any combination of hardware, software, and/or firmware. It should further be appreciated that each of the above-mentioned modules may, in various embodiments, represent a logical partitioning of supported functionality. This logical partitioning is depicted for ease of explanation of the functionality and may not be representative of the structure of software, hardware, and/or firmware for implementing the functionality. Accordingly, it should be appreciated that functionality described as being provided by a particular module may, in various embodiments, be provided at least in part by one or more other modules. Further, one or more depicted modules may not be present in certain embodiments, while in other embodiments, additional modules not depicted may be present and may support at least a portion of the described functionality and/or additional functionality. Moreover, while certain modules may be depicted and described as sub-modules of another module, in certain embodiments, such modules may be provided as independent modules or as submodules of other modules.

[0041] Although specific embodiments of the disclosure have been described, one of ordinary skill in the art will recognize that numerous other modifications and alternative embodiments are within the scope of the disclosure. For example, any of the functionality and/or processing capabilities described with respect to a particular device or component may be performed by any other device or component. Further, while various illustrative implementations and architectures have been described in accordance with embodiments of the disclosure, one of ordinary skill in the art will appreciate that numerous other modifications to the illustrative implementations and architectures described herein are also within the scope of this disclosure. In addition, it should be appreciated that any operation, element, component, data, or the like described herein as being based on another operation, element, component, data, or the like can be additionally based on one or more other operations, elements, components, data, or the like. Accordingly, the phrase “based on,” or variants thereof, should be interpreted as “based at least in part on.”

[0042] The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the block may 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 may 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 illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts or carry out combinations of special purpose hardware and computer instructions.