A Hybrid-based Error Detection Technique for PLC-based Industrial ...

A Hybrid-based Error Detection Technique for PLC-based Industrial Control Systems Navid Rajabpour, Yasser Sedaghat Dependable Distributed Embedded Systems (DDEmS) Laboratory Computer Engineering Department, Ferdowsi University of Mashhad Mashhad, Iran [email protected], [email protected] Abstract—Nowadays, Industrial Control Systems (ICSs) are employed to monitor and control safety-critical industrial processes. A Supervisory Control and Data Acquisition (SCADA) system is an ICS to perform centralized monitoring and also to control field sites in long-distance communication networks. A SCADA is a distributed system composed of several Remote Terminal Units (RTUs) and a Master Terminal Unit (MTU). RTUs interface with field sensors, local control devices, and field actuators, and the MTU gathers data from RTUs, provides an operator interface to display information, and controls remote sites. RTUs are typically connected to the MTU through a client/server network. Since RTUs operate commonly in a harsh industrial environment, fault tolerance is a key requirement, especially for safety-critical industrial processes. Studies show that a significant number of transient faults caused by a harsh environment lead to control flow errors in the RTU’s processors. A control flow checking technique, called PLC-CFC, has been proposed to detect control flow errors in several RTUs in a SCADA system. The proposed technique can be applied to all ICSs which employ microcontrollers, microprocessors, PLCs, or personal computers as their RTUs. The proposed technique has been experimentally evaluated on a real ICS consists of some PLC devices and a main server. For experimental evaluation, 30,000 faults were injected on distributed system and the PLCCFC technique detected more than 96.76% of the injected faults. The performance and the memory overheads of the technique are about 18.12% and 16.17% on average, respectively. Keywords—Industrial Control System, SCADA, RTU, Fault Tolerance, Control Flow Checking, Fault Injection, PLC.

I.

INTRODUCTION

Industrial Control Systems (ICSs) refer to a set of mechanical, electrical and electronic devices employed to guarantee safe and successful execution of a complicated industrial process. These systems are typically employed to monitor and control the plants and industrial environments such as water, energy, oil and gas refining and transportation [1]. In these applications, which are commonly safety-critical, a system failure may lead to significant risks to the health and the safety of human’s life, serious damages to the environment, or serious financial and economical issues [2]. A Supervisory Control and Data Acquisition (SCADA) system is an ICS which controls large scale industrial processes included several sites over long distances [3]. A SCADA system composed of server or Master Terminal Unit (MTU) and several Remote Terminal Units (RTUs). RTUs 978-1-4673-7929-8/15/$31.00 ©2015 IEEE

interface with field sensors and local control devices and valve actuators. These units execute their configuration and software control programs and send their control and sensing data to MTU through a client/server communication network over the communication protocols, such as TCP/IP or Ethernet/IP [4, 20]. The MTU gathers data from RTUs to process and control the remote sites [5]. In a SCADA system, RTUs operate in an industrial environment, which is commonly a harsh environment [5]. In a harsh environment, transient faults (due to Electromagnetic Interferences (EMI), Power Supply Disturbances (PSD), radiations, high operating temperature, etc.) may occur in electronic devices (i.e. microprocessors and microcontrollers, memory, internal bus) in RTUs. This fault resulting in an inversion of a bit state (i.e. single bit flip). Presented studies in [6] show that transient faults in the electronic devices can cause control flow errors and data errors. Control flow errors refer to deviations from the normal instruction execution flow of the software program and data errors refer to alter the contents of memory variables or in a register. It has been proved that control flow errors account for 33% to 77% of all transient errors [6] and the remaining are converted to data error. Monitoring the execution of program in RTU by MTU is very important and a CFE error would prevent the program from performing properly. Therefore, RTUs should be equipped with a technique in order to be able to detect such errors, and Control Flow Checking (CFC) is one of the best techniques to detect the occurrence of control flow errors. Many of CFC techniques have been proposed since 1980s [6-17]. These techniques can be categorized into three types as hardware-based, software-based, and hybrid. In hardwarebased techniques, a redundant hardware such as a watchdog processor is employed to detect control flow errors by monitoring the behavior of a main processor [7]. Softwarebased techniques employ software redundancy to detect deviations in software program execution flow by signature monitoring mechanisms [8, 9]. These techniques have software code and performance overheads. In comparison with hardware-based techniques, software-based techniques are flexible, low cost and being easily updated and they have also a better maintenance facility [6]. In hybrid techniques, a software technique would be merged with a hardware-based technique, in order to make balance between overheads and costs and have advantages of both software-based and hardware-based techniques.

In this paper, a hybrid control flow checking technique is presented to monitor and control the program execution flows of several RTUs in a SCADA system as a distributed system. The presented technique, called PLC-CFC, composes of two parts. A software-based control flow checking technique has been embedded in each RTU and the MTU processor, along with doing its tasks, is employed to monitor the program execution flow of all RTUs. The PLC-CFC technique can be applied in all industrial control systems which employ microcontrollers, microprocessors, PLCs, or personal computers. As a case study, the proposed technique has been applied on a real ICS in Parin Beton Amood Company, manufacturing “Autoclaved Aerated Concrete” in Mashhad, Iran. The mentioned ICS includes PLC devices as its RTUs and a main server as its MTU. To evaluate the fault coverage of PLC-CFC technique, 30,000 faults were injected on a real ICS. Among all injected faults, the PLC-CFC technique detected more than 96.76% of the faults.

program. These instructions produce some signatures and send them to a redundant hardware device as an external monitor. In these techniques, the control flow checking is done partly in the program (employing software-based techniques) and partly in the redundant hardware. CFCBTE [18], SWTES [10], PECFC [21], are the samples of hybrid techniques.

The paper is organized as follows. In Section 2, several related studies are introduced. The PLC-CFC proposed technique will be explained in details in the third section. The experimental results of the proposed technique are presented in Section 4. Finally, conclusion is drawn in section 5.

To our knowledge, almost all control flow checking techniques have been proposed to protect a single processor from control flow errors; while, SCADA is a distributed system composed of several RTUs and a MTU connected to a communication network. RTUs and MTU include a microcontroller, a microprocessor, a PLC, or a personal computer as their main processor. To protect SCADA from control flow errors it is necessary to employ a distributed control flow checking technique. In this paper a hybrid control flow checking is proposed for distributed systems.

II.

PREVIOUS STUDIES

Control flow checking techniques are typically employed signature monitoring mechanisms to check the execution flow of a program. Before the system’s run-time, an abstract of the program for the correct program execution is extracted. Afterward, several signatures, representing the chosen abstract, are assigned to the program. During the run-time, signatures are again generated in real-time and are compared with the stored, expected signatures. If a disagreement occurs, the occurrence of a control flow error is detected and reported [10]. As mentioned before, control flow checking techniques can be categorized into three main types. In hardware-based techniques, to detect control flow errors a hardware device, such as a watchdog processor or a watchdog timer, is utilized to check the execution flow of a program or to trace memory accesses. In these techniques, the behavior of the main processor is monitored using only redundant hardware devices. Therefore, these techniques, commonly designed for a special purpose, cannot be easily changed or updated, and impose considerable costs due to redundant hardware. Watchdog timer [11] and Lock stepping [12] are the samples of hardware-based techniques. In software-based techniques, several redundant instructions are inserted into a program to check the execution flow of the program. These techniques do not have any hardware overhead. The main advantages of software-based techniques are low cost and flexibility (easily changeable). However, these techniques impose significant performance and memory overheads due to the redundant instructions. Moreover, since the monitoring is done by inserted instructions into the program, these techniques cannot detect the program crash failure. CFCSS [14, 15], ECCA [13], RSCFC [16], I2BCFC [22], and SCFC [17] are the samples of software-based techniques. In the hybrid control flow checking techniques, redundant instructions are inserted into a

In the SWTES technique, a software-based technique using encoded signatures monitors the behavior of a program and an on-chip microcontroller timer has been exploited as a watchdog timer to detect the program crashes. This technique is experimentally evaluated on an ATMEL MCS51 microcontroller. The CFCBTE is a hybrid control flow checking technique for the PowerPC processors. In this technique, beside redundant software codes which are employed to compare signatures, three hardware-based mechanisms, i.e., Machine Check Exception, watchdog timer, and Branch Trace Exception, have been utilized.

III.

PLC-CFC TECHNIQUE

The current study presents a control flow checking technique, namely PLC-CFC technique, monitors the program execution using encoded signatures and performs partly on the MTU and partly on each RTU. This technique aims to detect the occurrence of control flow error. Fig. 1 shows a control flow error between two basic blocks and can be classified into illegal intra-block jump and illegal inter-block jump. An intrablock jump is an illegal movement within a basic block, and inter-block jump refers to incorrect jump between two blocks. This technique attempts to detect both intra-block and interblock jump. After error detection, control is transferred to the procedure, called CFE-Handler, to correct this control flow error. This procedure has the capability of detect the basic block in which error occurred. It transfers the control to the beginning of that basic block.

Fig.1. detection and correction of control flow errors

A. PLC-CFC Technique Implementation in RTUs To implement the local checking the control flow of an RTU’s program, three steps should be taken as follows: 1) Dividing the program into procedures, and partitioning the procedures into some basic blocks.2) Assigning two unique signatures to each basic block. 3) Inserting added instructions to the program. Step 1. Dividing the Program Code First, the RTU’s program code divided into some procedures, then procedures partitioned into several basic blocks. The basic block is a maximal set of ordered nonbranching instructions that is no jumping or branching instruction in a basic block except for the last one [14]. A program can be represented by a directed graph, called Control Flow Graph (CFG); nodes are the basic blocks and the arcs represent a control flow transfer between the basic blocks. Fig.2 shows a simple programs and an example of a CFG. // basic block 1 int number; int index, swap; while (number> 1){ // basic block2 index = 0; while (index< number - 1){ if (x[index] > x[index + 1]){ // basic block3 swap = x[index]; x[index] = x[index + 1]; x[index + 1] = swap; } // basic block4 index++; } // basic block5 number--; } (a) a simple source code

(b) the control flow graph

Fig.2. A simple code and its related CFG of a bubble sort program

Step 2. Assigning Signatures Four kinds of static signatures that used in the proposed technique are as following: a) In each basic block, a unique signature should be assigned to each basic block, called Detection Signature (DS). The DS of each basic block demonstrates the successor blocks of the current basic block. Bits related to successor blocks of the present block equal 1. As shown in Fig. 3(a), the DS contains three fields. The first field (T) represents the type of the signature and value of this field is 1.The second field (Pn) specifies the number of procedures in which basic block located. In a program, if the number of procedures equals N, second field would include N bits. If the maximum number of basic blocks in one procedure is N, then the third field of the DS, which represents the signature’s value, have N bits. In this variable, the ith and jth bits are set to 1, if the BBi and BBj are successors of the current basic block. This field contains the assigned signature of the related basic block. b) Another type of signature dedicates to each basic block that has a similar structure as signature type (a) and represents a unique identification number. As seen in Fig. 3(b) this signature includes three fields. First and second field are similar to signature type (a) and third field represents unique

number of each basic block. This field would have N bit, if the number of basic blocks equals N. T

Pn

Inter-block bits

(a)

T

Pn

Intra-block bits

(b)

T

RTUn

Sending Time

(c)

T

RTUn

DS

DSinter

DSintra

(d)

Fig.3.The structures of four types of signatures in the PLC-CFC technique

c) An Alive Signature (AS) would be sent from RTUs to the MTU in certain periods of time. These periods are determined by the MTU in the configuration time of RTUs. Receiving an AS from an RTU informs the MTU that the sender RTU has not been crashed. As shown in Fig.3(c) the signature has three fields. The first field (T) represents the type of the signature and value of field is 3. The second field represents number of an RTU which has sent the signature. The third field shows the time of sending the AS in the RTU. d) An Error Signature (ES) is sent when a control flow error being detected in an RTU by its local monitoring mechanism. Therefore, when an error occurs, programs control would be transferred to CFE-Handler procedure, which has two tasks. First, finding the basic block in which errors occurred by checking the value of the fields in ES. Second, sending an ES to MTU to handle error in RTU by checking the value of ES fields, in case that RTU crashes or cannot execute the program. Meanwhile, the technique has been designed in a way that if an error occurs in each basic block, it would be detected in next basic block and detection latency would be reduced. Therefore, CFE-handler needs ES signature fields. As shown in Fig. 3(d), the ES has five fields. The first field (T) represents the type of the signature and value of this field is 4. The second field represents number of an RTU which has been encountered a control flow error. The third field (DS) shows that the illegal jump occurred in which basic block and which procedure. The fourth field DSintra and the fifth field DSinter represents two assigned signatures of a basic block, in which a control flow error has occurred. Assessing these fields, the MTU discovers that a control flow error has occurred in which RTU and which basic block of that RTU’s program (current basic block in that RTU). Step 3. Inserting Added Instructions Some instructions have been added in the beginning, the middle and the end of each basic block to check the control flow of an RTU’s program. Fig. 4 shows the structure of each basic block after inserting the redundant instructions. Three variables have been used in this structure. The DSinter variable which has the signature type (a) structure is used to detect inter-block illegal jumps and in compile phase of a program dedicated to each basic. The DSintra variable which includes signature type (b) structure, represents the number of a basic block and is used to detect intra-block illegal jumps and introduced in compile phase of a program. The DS variable contains the run-time signature for error detection

with initial value of the signature of the entry block. This variable is updated in the end of the current basic block. DS= DS ⊕ DSintra Instruction 1 ……. Instruction n/2

DS= DS ⊕ DSinter Instruction n/2+1 ……. Instruction n

IF (DS DSintra) gotoCFE-Handler Update DS Fig.4. a basic block with added instructions

The DS variable initialized with DSinter variable which is related to the first basic block. As shown in Fig. 4, in the beginning of each basic block, new value of DS can be calculated as follows: DS = DS ⊕ DSintra, where “⊕” is a bitwise XOR operation. In the middle of each basic block, The DS value that has been calculated at the beginning of each basic block alters in the middle of each basic block by DS = DS ⊕ DSinter instruction. At the end of each basic block the value of DS would equal DSintra, if the value of DS has been calculated correctly at the beginning and the middle of each basic block and no intra-block or inter-block illegal jump occur.

The PLC-CFC technique divides a basic block into two parts. Analyses show that this technique can detect almost all illegal branches to a basic block from another basic block, even for branches from the first part of a basic block to its second part. If the number of the instructions would be too much, it is possible to divide a basic block into four or six parts, instead of just two parts, and execute XOR operation on run-time and static signatures of these parts in order to detect more intra block illegal jumps. Despite the software-based techniques, the proposed technique is able to detect the program crash, employing by the MTU. Fig. 5 illustrates the control flow graph of the bubble sort benchmark (presented in Fig.2), after applying the PLC-CFC technique on it. B. PLC-CFC Technique Implementation in the MTU As mentioned before, an Alive Signature (AS) is sent to the MTU by each RTU in a certain period of time. Receiving an AS from an RTU shows that the RTU has not been crashed. In the configuration time of an ICS, the MTU configures and programs each RTU. In this technique, at the configuration time, the time period of sending AS is set for each RTU and a profile for each of them is created in the MTU. After receiving a signature from an RTU, the MTU recognizes the type of the signature. If the received signature is an AS, the MTU checks the “sending time” field of the signature and compares it with the “sending time” of the last received AS stored in the RTU’s profile. The MTU detects a control flow error in that RTU, if the time between two received Alive Signatures is more than the predetermined time period, which is also stored in that RTU’s profile. Inserting “sending time” into an Alive Signature ensures that network latencies cannot affect the correctness of the technique. In this situation, the network latency can only cause to detect a control flow error, later. Moreover, if a received signature from an RTU is an ES, the content of the signature show that a control flow error has been occurred in which basic block of the RTU’s program. Employing this feature, the MTU can display the information to its human operator to select the best strategy to encounter the problem. C. Overhead Analysis of the PLC-CFC Technique When an error detection technique is implemented on a main program, there are different parameters which impose overheads on a system. Therefore, to improve the proposed technique, the trade-off between parameters should be considered. In this section, the overhead that PLC-CFC technique imposed on SCADA system will be presented.

Fig.5.The structures of basic blocks in the proposed technique

In order to reduce detection latency, it is possible to insert the instructions, which have been added at the beginning, to the end as well. So, the error detection would be occurred in the basic block and CFE-Handler would be run.

The proposed technique has some memory and performance overheads due to inserted instructions into the main program. Some instructions which have been added at the beginning, in the middle or at the end of each basic block; But, the error detecting capability will increase and detect latency will decrease. Therefore, these instructions being customized and make a trade-off between parameters. The PLC-CFC technique presented in a SCADA distributed network. Thus, network traffic is an overhead,

because only Alive Signatures are sent over the network in the error free conditions. Moreover, the time period of sending these signatures is adjustable due to the network’s properties. In addition to Alive Signatures, Error Signatures are only sent over the network when an error occurs in an RTU. In addition, since the sending time of an Alive Signature is stored in the signature, the network latency cannot affect the correctness of the technique. This latency can cause the MTU to detect an RTU’s program crash with some delays. Furthermore, if new RTUs being added to network, then the number of Alive Signature will increase and lead to network latency. Thus, regarding SCADA structure and number on RTUs and Alive Signature sending time it would be possible to make a tradeoff.

Branch Modification: the target address of a control instruction is being modified. By use of the mentioned fault models, the behavior of a CFE in memory can be exactly modeled. These models are not capable to represent the CFE behavior due to an error occurred in processor internal registers. In these cases, the behavior of such errors can be modeled by manipulating Programs Counter (PC) and Status Register (SR). The control flow errors will be produced and also the efficiency of different techniques can be compared with each other by applying above mentioned fault models. The faults are randomly injected to the assembly code of benchmarks. By changing registers and program counter of the program, control flow errors would occur in the program. Thus, the efficiency of different techniques can be evaluated.

Compared with the other typical control flow checking techniques, the PLC-CFC technique does not impose any hardware redundancy. In this technique, the existed MTU is also employed as a hardware monitor. And for monitoring there is no need to add a watchdog for each RTU and therefore it would cause cost decrease in system.

Seven versions are considered for each benchmark. First is the original code (the code of the benchmark), to which other six techniques being applied. For each version, the fault injection randomly executed, based on fault models. According to the effects of the injected faults in the RTU’s program, five different cases occur: • Correct Result (CR): injected fault does not change the final result of the program and no control flow error is detected. • Wrong Result (WR): fault results in a wrong output and is not detected by the PLC-CFC technique. • Time Out (TO):injected fault caused the program execution time to change and it does not finish in a specified time. This type of errors is detected by the MTU in the PLC-CFC technique. • Os Exception (OS): These faults cause the operating system exception. Generally, this percentage of faults is regarded as being detected by the operating system. • Single Detection (SD): injected fault results in a control flow error and is detected by techniques in the RTU. For experimental evaluation the PLC-CFC technique was applied to PLCs and 30,000 faults were injected into the mentioned benchmarks. Table2 shows the experimental results of the original program and PLC-CFC programs, respectively. For two versions, according to the effects of the injected faults in the PLC’s programs, five different cases occur. The occurrence percentages of these cases are shown in Table2.

IV.

EXPERIMENTAL RESULTS

To evaluate the proposed PLC-CFC technique, the technique was applied to a real ICS distributed network consisted of three Steam Boiler (Steam boiler is basically a closed vessel into which water is heated until the water is converted into steam at required pressure) devices and three RO (Reverse osmosis is a process in which dissolved inorganic solids such as salts are removed from a solution such as water)devices as RTUs and an HP server as MTU. There have been three PLC modules set up above mentioned machines, and are being monitored by HP server through a client/server communication network. SIMATIC S7 software installed on the server and some benchmarks, with STEP7 programming language, implemented on PLCs [23]. Benchmarks specifications have been shown in Table 1. PLC’s are widely used in the industry due to their potential benefits like easy in programming, reliability and flexibility in use for communication with plant computers. To provide a PLC-based Benchmark, in this paper, the standard used in [24] has been applied. Table 1. Benchmark programs used in the experiments and comparison the

performance and the memory overheads Benchmarks

Devices

PLC Models

#Basic blocks

#Procedure

R200E R200S R300S

Reverse osmosis1 Reverse osmosis2 Reverse osmosis3 Steam Boiler1 Steam Boiler2 Steam Boiler3

SIMATIC ET200 SIMATIC S7-200 SIMATIC S7-300

35 38 41 37 42 45

12 12 15 17 19 20

SB200E SB200S SB300S

SIMATIC ET200 SIMATIC S7-200 SIMATIC S7-300

To evaluate the technique, the PLC-CFC technique was applied to PLCs and 30,000 faults were injected into the mentioned benchmarks. Fault injection approach is used that has three kinds: 1) Random Branch Insertion: replacing a non-control instruction with a control instruction. 2) Random Branch Deletion: deleting some branches of the program randomly. 3) Random

Table2. Experimental evaluation results of No CFC, and PLC-CFC technique (CR: correct result, WR: wrong results; TO: time out; OS: Os Exception; SD: single detection; FC: fault coverage) Techniques

Benchmarks

R200E R200S R300S No CFC SB200E SB200S SB300S Average R200E R200S R300S PLC-CFC SB200E SB200S SB300S Average

CR

WR

TO

OS

SD

14.20 13.80 15.00 12.90 13.80 11.65 13.56 10.55 10.05 10.90 11.26 11.61 12.20 11.10

64.45 64.15 63.80 65.10 62.90 59.20 63.27 2.91 3.05 2.78 2.60 2.88 3.09 02.89

11.60 12.09 10.67 12.90 11.45 09.60 11.39 7.15 7.20 7.06 6.80 6.85 7.02 07.01

09.75 09.96 10.53 09.10 11.85 19.55 11.79 7.90 8.20 8.40 7.84 8.30 8.50 08.19

00.00 00.00 00.00 00.00 00.00 00.00 00.00 71.49 71.50 70.86 71.50 70.36 69.19 70.82

FC 24.88 25.58 24.94 25.26 27.03 32.99 26.78 96.75 96.61 96.88 97.07 96.74 96.48 96.76

The fault injection average results in the six benchmarks for some techniques running on the RTU have been presented

in table3. Among all 30,000 injected faults, 11.10% faults lead to correct output results. Among all the remaining injected faults, only 02.89% injected faults, which result in wrong output results, were not detected by the PLC-CFC technique. Therefore, the fault coverage of the proposed technique is about 96.76%. Table3. Experimental evaluation average results of CFCSS [14, 15], ECCA [13], RSCFC [16], I2BCFC [22], SCFC [17], and PLC-CFC techniques Techniques

CR

WR

TO

OS

SD

CFCSS ECCA RSCFC I2BCFC SCFC

19.39 17.33 15.04 14.77 13.79 11.10

19.71 17.90 13.02 08.85 05.29 02.89

07.89 07.78 07.29 07.15 07.45 07.01

10.30 09.20 10.64 09.10 08.92 08.19

42.71 47.79 54.01 60.13 64.55 70.82

PLC-CFC

Table4 presents average fault coverage for some techniques and also shows the memory and the performance overheads in average for the above mentioned techniques. The performance overhead of the PLC-CFC technique, due to execution of the redundant instructions, is about 18.12%. The memory overhead of the proposed technique, due to insertion of redundant instructions into basic blocks of a program and signature variables, is about 16.17%. Table4. Comparison the performance and memory overheads, fault coverage and evaluation result Techniques

CFCSS ECCA RSCFC I2BCFC SCFC PLC-CFC

Performance Overhead

Memory Overhead

Fault Coverage

Evaluation Result

22.61% 22.87% 23.50% 23.97% 24.02% 18.12%

20.05% 20.23% 20.80% 21.25% 21.34% 16.17%

75.55% 78.35% 84.68% 89.62% 93.86% 96.76%

51.33 53.04 56.76 59.62 62.37 70.51

Moreover, the new parameter Evaluation Result(ER), which has been defined, would cover fault coverage, memory and performance overheads concurrently. This technique should be able to balance these parameters with each other. The ER is defined as follows: ER

Fault Coverage 100 Memory Overhead Performance Overhead

( 1)

Table4shows ER for some techniques, in which PLC-CFC has greater ER than other techniques and is more appropriated for employing in safety-critical systems. The PLC-CFC technique does not impose any hardware redundancy, compared to other typical hybrid-based control flow checking techniques. The existed MTU is also employed as a hardware monitor. It should be noted that in PLC-CFC technique, RTUs send the signatures to the MTU over the network without any effect on the performance of the RTUs.

V.

CONCLUSIONS

Industrial Control Systems (ICS) are essential factors to ensure execution of an industrial process safe and successfully. SCADA system, a type of an ICS, is a widely distributed system primarily used to remotely control and

monitor of industrial processes from a central location. SCADA covers the transfer of data between a server as MTU and a number of remote sites as RTUs. Since an RTU works in a harsh environment, fault tolerance is one of the most significant among many challenges in industrial networks. In this paper, a hybrid control flow checking technique, called PLC-CFC, was proposed in order to detect control flow errors in RTUs. This technique is employed to monitor the program execution flows of several RTUs in a SCADA system as a distributed system. The proposed technique can be applied to all ICSs which employ microcontrollers, microprocessors, PLCs, or personal computers as their RTUs. The experimental results showed that among a total of 30,000 injected faults on distributed network, and the presented technique detects more than 96.76% of them.

ACKNOWLEDGEMENT The authors would like to appreciate Parin Beton Amood Company for providing the opportunity of field work and evaluation of the PLC-CFC technique in a real Industrial Control System.

REFERENCES [1]

M. B. Mollah and S. S. Islam, “Towards IEEE 802.22 Based SCADA System for Future Distributed System,” Proc. of IEEE International Conference on Informatics, Electronics & Visio, Dhaka, Bangladesh, 1819 May 2012,pp.1075-1080. [2] B. Atlagic, D. Milinkov, M. Sagi, and B. Bogovac, “High-Performance Networked SCADA Architecture for Safety-Critical Systems,” Proc. of the Second Eastern European Regional Conference on the Engineering of Computer Based Systems, Bratislava, Slovakia, 5-6 September 2011, pp. 147–148. [3] M. Avhad , V. Divekar, H. Golatkar and S. Joshi, “Microcontroller based Automation System Using Industry Standard SCADA,”Proc. of Annual IEEE India Conference, Mumbai, India, 13-15 December 2013, pp. 1-6. [4] Z. Qiang and C. Danyan, “Design and Implementation of Distribution Network SCADA System Based on J2EE Framework,” Proc. of International Forum on Information Technology and Applications, Chengdu, China, 15-17 May 2009, pp. 633-636. [5] S. Misbahuddin, “Fault Tolerant Remote Terminal Units (RTUs) in SCADA Systems,”Proc. of International Symposium on Collaborative Technologies and Systems (CTS), Chicago, USA, 17-21 May 2010, pp. 440–446. [6] L. Tan, and Y. Tan, J. Xu, “CFEDR: Control-Flow Error Detection and Recovery Using Encoded Signatures Monitoring,”Proc. of IEEE International Symposium on Defect and Fault Tolerance in VLSI and Nanotechnology Systems (DFT), New York, USA, 2-4 October 2013,pp. 25-32. [7] A. Mahmood and E. J. McCluskey, “Concurrent error detection using watchdog processors-a survey,” Journal of IEEE Transactions on Computers, vol. 37, Issue. 2, 6 August 2002, pp.160-174. [8] S. Makoto, “A Dynamic Continuous Signature Monitoring Technique for Reliable Microprocessors,” Journal of IEICE Transactions on Electronics,vol. 94, Issue. 4,April 2011, pp. 477-486. [9] Y. Y. Chen, and K. L. Leu, “Signature-monitoring Technique based on Instruction-bit Grouping,”IET Proc. of Computer Digital Techniques, vol. 152, Issue. 4, July 2005, pp. 527-536. [10] Y. Sedaghat, S.G. Miremadi, and M. Fazeli, “A Software-based Error Detection Technique Using Encoded Signatures,” Proc. of the 21st IEEE International Symposium on Defect and Fault-Tolerance in VLSI Systems (DFT'06), Arlington, USA, 4-6 October 2006, pp. 389-400.

[11] A. Benso, S. D. Carlo, G. D. Natale, and P. Prinetto, “A Watchdog Processor to Detect Data and Control Flow Errors,” Proc. of the 9thIEEE On-Line Testing Symposium, 9-7 July 2003,pp.144-148. [12] Horst RW, Harris RL and Jardine RL, “Multiple Instruction Issue in the Nonstop Cyclone Processor,”Proc. of the 17th international symposium on computer architecture, Seattle, Washington, USA,28-31 May 1990, pp. 216–26. [13] B. Nicolescu and R. Velazco, “Detecting Soft Errors by a Purely Software Approach: Method, Tools and Experimental Results,” proc. of the Design, Automation and Test in Europe Conference and Exhibition (DATE ’03), Munich, Germany, 3-7 March 2003, pp. 57-62. [14] N. Oh, P. P. Shirvani, and E. J.McCluskey, “Control-flow checking by software signatures,” Journal of IEEE Transactions on Reliability, vol. 51, Issue. 1, March 2002, pp. 111–122. [15] Yu J, Garzaran MJ and Sni M. “Techniques for efficient software checking,” Proc.of the 20th international workshop on Languages and Compilers for Parallel Computing (LCPC’07), Urbana, Illinois, USA, 11–13October 2007,pp. 16–31. [16] A Li and B. Hong, “On-line Control Flow Error Detection Using Relationship Signatures among Basic Blocks,” Journal of Computers andElectrical Engineering, vol. 36, Issue. 1, Elsevier, January 2010, pp. 132–141. [17] S. A. Asghari, H. Taheri, H. Pedram, and O. Kaynak, “SoftwarebasedControl Flow Checking against Transient Faults in Industrial Environments,” Journal of IEEE Transactions on Industrial Informatics, vol. 10, Issue. 1, IEEE, February 2014, pp. 481–490. [18] M. Fazeli, R. Farivar, and S.G. Miremadi, “Error Detection Enhancement in PowerPC Architecture-based Embedded Processors,” Journal of Electronic Testing: Theory and Applications(JETTA), vol. 24, Issue. 1-3, Springer, June 2008, pp. 21-33. [19] R.Leveugle, A. Calvez, P.Maistri, “Statistical Fault Injection: Quantified Error and Confidence,”Design, Automation & Test in Europe Conference & Exhibition, 2009. DATE '09, Nice, 20-24 April, pp. 502 506. [20] O. Rysavy, J. Rab and P. Halfar, “A Formal Authorization Framework for Networked SCADA Systems,”Proc. of the 19th International Conference and workshops on Engineering of Computer Based Systems (ECBS), Novi Sad, Serbia, 11-13 April 2012, pp. 298-302. [21] R.G.Regel and S. Parameswaran, “Hardware Assisted Pre-emptive Control Flow Checking for Embedded Processors to improve Reliability,” Hardware/Software Codesign and System Synthesis. Proceedings of the 4th International Conference, Seol Koria, 22-25 Oct. 2006,pp. 100 – 105. [22] S. A. Asghari, H. Taheri, H. Pedram, and A. Abdi, “An Effective IntraInter Block Control Flow Checking Method Against Single Event Upsets,” Research Journal of Applied Sciences, Engineering and Technology, 01 November 2012,pp.4367-4379. [23] Li-Ling Wang, Hong-Ying Wei, “Development of a Distributed Control System for PLC-based Applications,”International Conference onMachine Learning and Cybernetics (ICMLC), Qingdao, 11-14 July. 2010, pp. 906 – 909. [24] F. Basile and P. Chiacchio, “A Novel Approach to PLC Programming for Distributed Automation Systems Control,” IEEE Conference on Emerging Technologies and Factory Automation (ETFA), Bilbao, 13-16 Sept. 2010, pp. 1– 8.