Dependability Evaluation of WirelessHART Best Practices

Transcription

1 Dependability Evaluation of WirelessHART Best Practices Ivanovitch Silva and Luiz Affonso Guedes DCA, Federal University of Rio Grande do Norte Natal, Brazil Paulo Portugal and Francisco Vasques ISR/IDMEC, FEUP, University of Porto Porto, Portugal Abstract WirelessHART currently appears as a promising solution for the last mile connection in process control applications. Most of these applications have stringent dependability requirements, where a system failure may result in economic losses, or damage for human life or the environment. Among the different type of faults that can lead to a system failure, permanent faults on network devices have a major impact. They can hamper communication over long periods of time and consequently they may disturb, or even disable, control algorithms with all resulting problems. In this work we perform a dependability evaluation of the best practices indicated by the HART Communication Foundation (HCF), when network devices are subject to permanent faults. 1. Introduction Traditionally, distributed applications in industrial environments are supported by wired communication networks [14]. However, the industry has recently shown interest in moving part of the communication infrastructure from a wired to a wireless environment in order to reduce costs related with installation and maintenance. In this context, WirelessHART is actually being considered as a promising candidate to be adopted as the communication solution for the last mile connection in process control applications. Among several advantages, the absence of a wired infrastructure enables a WirelessHART network to obtain information in a simpler way than traditional instrumentation techniques [21]. Industrial applications have usually stringent dependability requirements (reliability, availability and safety), since faults may lead to system failures which can result in economic losses, or damage for human life or the environment [8]. Considering a communication network, faults can be classified as transient or permanent [4]. Transient faults usually affect communication links between network devices and are typically caused by noise or electromagnetic interferences 1. Permanent faults affect network 1 Transient faults can also affect network devices, but this type of faults will not be considered on this work. devices and have their origin in hardware malfunctions. After the occurrence of a permanent fault, the device will only became operational again after being repaired. In this paper we focus on permanent faults that affect network devices leading to its failure. Permanent faults have typically a major impact on the system operation. Their immediate consequence is the communication impairment with the affected devices. In worst case scenarios, several network devices can become isolated, as in the case of a router failure. As a result, control applications may be disturbed or even disabled, which may lead to a system failure. The use of an adequate methodology to evaluate the dependability of WirelessHART networks can anticipate important design decisions. Namely, regarding its topology, criticality of the devices, redundancy aspects and network robustness. This information can be used during the system s life-cycle, and in particular on the early planning and design phases. E.g. depending on the topology, alternative paths to the gateway can be created to improve the overall reliability of the network. In the same way, if a sensitivity analysis is supported, critical devices can be identified and decisions about different redundancy approaches can be taken. The main contribution of this paper is on the dependability evaluation of WirelessHART networks when configured according to the best practices suggested by the HART Communication Foundation (HCF). We focus on the network s reliability and availability. The evaluation is conducted according to a methodology developed previously by us to assess the dependability of industrial wireless networks subject to permanent faults [17]. The remainder of this paper is organized as follows: Section 2 presents an overview of WirelessHART and also of the best practices suggested by the HART Communication Foundation (HCF). In Section 3, we survey some relevant works on dependability evaluation of wireless networks. In Section 4, we describe briefly the Fault Tree Analysis (FTA) method, and present the methodology used for the proposed evaluation. Section 5 presents the results from the dependability evaluation, considering different fault scenarios and using the rules indicated by the HCF best practices. Finally, Section 6 concludes the paper and present directions for future works.

2 2. WirelessHART WirelessHART is an extension of the HART protocol to support wireless communication. In September 28, the WirelessHART specification (HART 7.1) was approved by the International Electrotechnical Comission as a public available specification: IEC [2]. WirelessHART was the first industrial wireless communication technology to attain this level of international recognition [18]. WirelessHART defines eight types of devices, as presented in Figure 1: network manager, network security, gateway, access point, field device, adapter, router and handheld device. All devices connected to the wireless network implement basic mechanisms to support network formation, maintenance, routing, security and reliability. Adapter Plant Automation Network Network Manager and Security Manger Router Gateway Access Point Field Device WirelessHART Handheld Figure 1. WirelessHART devices. WirelessHART has a physical layer based on IEEE , but implements its own medium access control (MAC) sublayer. The MAC is based on a TDMA (Time Division Multiplexing) scheme that uses superframes. Superframes are composed by slots, and the number of slots indicates the periodicity of the superframe. To support different transmission intervals, a WirelessHART network can use multiple superframes with different number of slots. Each slot has a fixed duration of 1ms, which is enough to transmit a packet and receive an acknowledgment (the maximum packet size is 133 bytes including headers). Slots can be dedicated or shared. The use of dedicated slots is more common. Shared slots are used for transmission retries and advertising indication during the join procedure. A slot supports up to 15 channels, thus, theoretically 15 devices can simultaneously transmit during the same slot time. The standard uses a frequency hopping mechanism and a channel blacklist to minimize the influence of noise in the network operation and consequently to increase the communication reliability. Another way to increase the communication reliability is providing redundant paths between the gateway and field devices. This redundancy is achieved through selforganizing and self-healing mesh networking techniques. Messages can be routed using two different approaches: source routing and graph routing. The former is mostly used for diagnostic purposes, as it establishes a single path between a field device and the gateway. On the latter, each device along a path to the destination has the option to decide between multiples neighbors to forward a message. A third possibility to provide redundancy would be the use of spare devices. However, the use of this type of devices is not specified in the WirelessHART standard [2]. In order to guide the application designers, the Hart Communication Foundation developed a set of best practices for implementing reliable WirelessHART networks [6]. Basically, the following three fundamental rules are suggested: Rule of five: every WirelessHART network should have at least five field devices within the communication range of the gateway. It is expected a proper behavior of the network when there are less than five devices in the neighborhood of the gateway. However, according to HCF, the best results are attained with at least five neighbors. Rule of three: every field device should have at least three neighbors. This property is used to guarantee that each field device has at least two paths to the gateway. If a neighbor fails, the third neighbor is used as a backup route. Rule of 25%: in large networks, at least 25% of field devices should be within the gateway communication range. Its important to realize that the localization of WirelessHART devices is driven by the process requirements, and in many cases the fundamental rules are difficult to attain. Thus, it can be necessary to add devices with a unique goal of attaining route purposes or to guarantee adequate self-organizing and self-healing mesh networks. 3. Related Work The network reliability problem is a classical reliability analysis problem [3] that can be classified as: k-terminal, 2-terminal or all-terminal. Suppose a network with N devices and a set of K devices (K N and K < N ). K is a set composed of a sink node and K -1 field devices. Defining a sink device s K, the k-terminal problem is expressed as the probability that there is at least one path from s to each field device in K. The 2-terminal problem is the case where K = 2, whereas the all-terminal problem is the case where K = N. These cases are known to be NP-hard problems, however bounding algorithms can be found for networks with limited size [5]. The network reliability problem has been widely studied for wired networks. For example, in [7] the author

3 deals with the problem of measuring the reliability and availability of a wired network assuming hardware and software failures. The author gives an important insight about the state-space enumeration and the topology adaptation strategy when failures occur. The main difference between the reliability analysis of wired and wireless networks is related to the dynamics of the network. In a wireless network, the dynamics is greater since links fail more often and also due to the mobility of devices. An early work about the reliability evaluation for a radio-broadcast network was conducted by [3]. In that work, the authors considered unreliable devices and reliable links and shown that the two-terminal reliability problem for radio broadcast networks is computationally complex. A WirelessHART network can be considered as a Wireless Sensor Network (WSN) designed for industrial environments. Thus, methodologies to evaluate the reliability of WSN can also be applied to WirelessHART networks. A methodology to evaluate the reliability of a WSN was proposed in [15]. The authors created a scheme based on reduced ordered binary decision diagrams (ROBDD) to model a cluster topology. They do not consider multiple paths connecting a device to the sink, thus it is not able to consider self-healing routing protocols. Common-cause failures were considered, focused in a single cluster. The proposed methodology does not support any failure condition based on combination of different cluster heads, neither identify the most critical devices. By introducing the concept of coverage-oriented reliability, the same authors extended this work and proposed other mechanisms to evaluate the reliability of a WSN [16]. They assumed that the network fails if a specific geographical point in the cluster is not covered by at least K devices. This gives a more flexible way to configure failure conditions. However, it does not allow to create two or more coverage subsets for the same cluster. It becomes clear from the above discussion that previous works only provide a partial solution for the envisaged problem. Most of them are focused in very specific scenarios and assume restrictive assumptions regarding the definition of network failure conditions, dependability metrics, topology, network reconfiguration and redundancy aspects, as well as applicability to industrial scenarios. The dependability evaluation of the best practices of WirelessHART networks performed in this paper uses a methodology that is not a new approach (the reliability network problem has already been evaluated in the literature), however, the adopted methodology aims to remove most of restrictions of previous works. 4. Methodology for Dependability Evaluation As previously discussed, the reliability evaluation of a general network is a NP-hard problem. Nevertheless, this problem can be tractable for a low-medium number of devices (5-1 devices), as it is the case of networks typically found in WirelessHART applications. Figure 2 overviews the methodology adopted in this paper. The process starts by providing information about the network topology, device types, device s failure and repair processes and network failure condition. The latter expresses the conditions that may lead to a network (system) failure and it is defined by a logical expression that combines the failure status of field devices. The next step is to find all the paths between the gateway and field devices that encompass the failure condition. This is necessary to attain flexible failure conditions and to support self-healing routing protocols. In the following step, a fault tree is generated using all the previous data. The SHARPE tool [2] is used to compute the metrics of interest. It is possible to evaluate the reliability, availability and mean time to failure (MTTF) of the network, as well as component s criticality factors [9] [12]. To automate the process we developed a software tool that executes the previously described steps. Further details about the proposed methodology can be found in [17]. 4.1 Fault Tree Analysis Fault Tree Analysis (FTA) can be used as an effective alternative to the aforementioned approaches ( 3) to evaluate the reliability and availability of a network. The main advantage of FTA is related both with the intuitive procedure used to describe the events that lead to a failure and the almost absence of the state space explosion problem [13], commonly found when modeling large systems [19]. Fault trees (FT) are a graphical model that represents the combination of events that may lead to a system failure. The model uses a treelike structure composed by events and logical gates [9]. Events represent either normal or faulty conditions, such as component failures, environmental conditions, human-made faults, etc. They are considered boolean, i.e., they either occur or not occur. Logical gates are used to represent the cause-effect relationships among events. Gate inputs are either single events or combinations of events which result from the output of other gates. There are several types of available gates, such as AND, OR and K-out-of-N (Figure 3) [9]. The process of building a FT is performed deductively and starts by defining the TOP event, which represents the system failure condition. From this event, and proceeding backwards, the possible root causes are identified. The events at the bottom of the tree are referred as basic events. If a basic event occurs two or more times in a FT it is called a repeated event. From a probabilistic point of view, the assessment of a FT consists of calculating the probability of the TOP event starting from the probabilities of the basic events. This calculation is performed differently for each type of gate. Assuming a gate with n independent inputs (events), where the occurrence of event i is described by a cumulative distribution function (CDF) F i (t), the gate output CDF is given according to the Figure 3. When an AND gate is used, the failure condition occurs

4 Device types Network failure condition Failure and repair data Topology Input Measures to compute Paths from gateway to devices that encopass the failure condition Fault Tree (Sharpe model) Analysis (Sharpe) Output Figure 2. Overview of the methodology for reliability and availability evaluation. Reliability MTTF Availability F t = 1 n i=1 or F i (t)... F n (t) (1 F i (t)) F t = n i=1 and F i (t) F i (t)... F n (t) F t = ( F i t )( 1 F i (t)) I k i I K out of N F i (t)... F n (t) Figure 3. Cumulative distribution function (CDF) for the gate output (and, or, k-out-of-n). only when all input events have occurred. On the other hand, when an OR gate is used, the failure condition occurs if at least one input event have occurred. Finally, if a K-out-of-N gate is used, the failure condition occurs if at least k input events have occurred. When a FT does not contain any repeated event, the probability of the TOP event can be obtained through a direct calculation, using the formulae presented in Figure 3. However, if there are repeated events these equations are no longer valid. In the literature we can find several techniques to deal with repeated events, such as inclusion-exclusion principle, sum of disjoint products, factorization and direct/indirect recursive methods [9]. It is possible to compute several dependability measures from a fault tree [9]. In the context of this work we focus on reliability and availability (discussed at 4.3.2). For complex topologies, the construction of a fault tree is a time-consuming task demanding much effort. The usual solution is to adopt an approach that automatically generates the fault tree as described in [1] Assumptions The main assumptions considered in this methodology can be summarized as follows: Topology: the network is composed of N devices, which can belong to one of the following types: field device (e.g. sensor/actuator node), router, access point and gateway. Devices are arranged according to one of the following topologies: line, star, cluster and mesh; Faults: only permanent faults are considered. The links, due their wireless nature, are only affected by i I transient faults, and thus are considered to be reliable (i.e. they do not fail). After a permanent fault, a device is considered failed (permanently). We assume that device failures are independent. Failure occurrences are characterized by a failure distribution, by means of a CDF. In principle any type of CDF can be used to characterize their occurrence. However, the use of the SHARPE tool imposes some restrictions. The tool imposes that a CDF must be expressed using exponential polynomial terms, as following: F (t) = n a j t kj e bjt (1) j=1 where the terms a j, k j and b j are the parameters of the polynomial. Many distributions can be expressed in this way (eg. exponential, Erlang, hypoexponential, hyperexponential) [13]. Other distributions (e.g. Weibull, deterministic) can be approximated using exponential polynomial terms. Further details can be found in [11]; Repairs: if necessary, field devices can be repaired after failure. After a repair operation the device is considered as new. We consider that all repair processes are independent and the number of repairman (i.e. number of repair actions) is not limited. The time necessary to repair a device is characterized by a repair distribution. This distribution is defined in analogous way to previously discussed failure distribution; Reconfiguration: when a device fails, the network topology can change. We assume that the network manager is able to identify a device failure, and then to update the topology supporting the use of selfhealing routing protocols. It is also assumed that the time required to perform this operation is negligible, and it is always successful (if alternative paths exist); Network failure condition: the network failure condition (NFC) defines which combination of devices may lead to a network failure and its equivalent to the TOP event. The methodology used in this paper supports any combination that can be expressed using boolean operators (i.e. AND, OR, K-out-of-N).

5 The failure condition associated to a field device i is defined as fc fd i. A combination of devices that may lead to a network failure is defined as nfc and j, where j is the identification of combination, which is represented by the AND gate of the failure conditions of each device. A device can belong to more than one failure condition. Figure 4 presents an example where the NFC is represented by a K-out-of-N gate of all combinations that may lead to the network failure. nfc_and fc_fd i and... NFC K-out of-n fc_fd k... and... nfc_and n Figure 4. Network failure condition Modeling Approach This section describes the the steps needed to build a model that represents a network failure Device failure condition After defining the NFC (Figure 4), it is necessary to define the conditions that may lead to the failure of a field device. We consider two possibilities: (i) its hardware has failed; (ii) there is no path between the device and the gateway (conectivity problem). In the former case, a device i is considered to be faulty if its hardware has failed. This is represented by event fd i (Fig. 5a). In the latter case a device fails if there are no paths between the device and the gateway. This is represented by event cp (Fig. 5a). This event is only active when all paths between the device 2 and the gateway have failed (Figure 5b). Finally, as described in Figure 5c, a path is considered to be faulty if at least a device (gateway (gtw i ), access point (ap i ), router (r i ) or field device (fd i ) along the path has failed. fc_fd i or cp and... fd i _Path k fd i cp fd i _Path i fd i _Path n gtw i, ap i, r i, fd i (a) (b) (c) Figure 5. Device failure condition. Note that it is necessary some effort to find all combinations that may lead to a connectivity failure. To attain 2 The device must belong to the NFC. or this, it is necessary to search all paths between the gateway and field devices that belong to the NFC. Paths are found performing a depth-first search (DFS) in an adjacency matrix that represents the WirelessHART network. All generated paths are stored in a data structure based on a fault tree SHARPE Model Using the information obtained in the previous steps (Figs. 4 and 5), a fault tree is then created. The next step is to transform the generated fault tree into a model suitable for SHARPE. The model is described using a specific notation defined by SHARPE, and also includes the measures to be computed [13]. SHARPE is able to compute several dependability measures (e.g. reliability, availability, MTTF), either numerically or symbolically (using exponential polynomial terms) in particular instants of time (transient) or in steady-state. Following, we briefly describe the input data necessary to compute these measures. In general, after obtaining the fault tree, it is necessary to replace each basic event of the tree by the reliability or availability function of each device. If we intend to evaluate the network reliability, then it is necessary to provide the reliability function of each device, R i (t). This function is the complement of the respective failure CDF ( 4.1) and is closely related with the failure rate function λ i (t), which describes the instantaneous failure rate of the device ( R i (t) = 1 F i (t) = exp t ) λ i (u)du If the failure rate is assumed to be constant λ i (t) = λ i [1], then the reliability is given by R i (t) = exp( λ i t). The output of the model will be reliability function of the NFC, R NF C (t). Another metric related with the reliability is the MTTF (Mean Time to Failure). Formally, it is defined as the expected (average) time during which a component is working properly and is given by MT T F i = (2) R i (t)dt (3) Therefore, knowing the R NF C (t), it is possible to compute directly its MTTF. If we are interested in evaluating the network availability, the procedure is slightly different. If failure and repair rates are constant, then we can use these parameters to compute the availability of each device, A i (t). In this case, A i (t) is given by [12]: A i (t) = µ i + λ i e (λi+µi)t (4) λ i + µ i λ i + µ i where λ i and µ i are respectively the failure and repair rates. Other distributions can also be supported by using the concept of model hierarchy provided by SHARPE. In

6 this case an availability model is developed first (e.g. using a two state model based on failure and repair CDFs) and its output is used as input of an higher model. In either cases the output of the model will be availability function of the NFC, A NF C (t). Finally, it is important to define if an event is basic or repeated. Depending on the type of event, the procedure to evaluate the reliability or availability is different [13]. The distinction between types of events can be held through a search in the events of the fault tree. If an event occurs only once, it is considered basic, otherwise it is considered repeated. 5. Dependability Evaluation In this section we present the results obtained when using the proposed methodology to evaluate the best practices suggested by the Hart Communication Foundation. The main target of the analysis is to highlight the influence of best practices upon the network reliability and availability. 5.1 Assumptions The main assumptions considered in this analysis are listed below: Topology: we consider a WirelessHART mesh network in conformance with the rule of five and the rule of three. Since there are many topologies where both rules can be observed, we choose to use a symmetrical topology with the gateway at the center (black circle) and field devices (white circles) placed according to an hexagonal pattern at fixed distances from the gateway (Fig. 6). The straight lines connecting devices represent the communication paths. The network is composed of 18 devices, where devices fd 9, fd 11, fd 15 and fd 17 act only as routers (gray circles). Consequently, the network failure condition is expressed considering only the other 14 devices (i.e. field devices that are monitoring process variables like temperature, level, etc.). It is important to stress that we consider that routers can fail, and we account indirectly them in the results by considering the paths between the gateway and field devices that include routers. Failure rate: we assume that device failures occur with a constant rate. This is a common assumption for electrical/electronic components [1]. Since we are interested in measuring relative trends rather than absolute values, failure rate values shouldn t have a major impact in the results. However, used values must be credible to get unbiased results. To simplify the procedure, we assume that all field devices (including routers) have the same failure rate. This is a reasonable assumption, since most devices use similar hardware (e.g. communication radio, microprocessor, memory, etc). We assume a MTTF = 1 years for each device, which is equivalent to a failure rate of λ 1E-5 (hour 1 ). This value is also reasonable, since it corresponds to the average useful life of this type of devices. Since the gateway is typically more reliable than other network devices, we assume that its failure rate is one order of magnitude smaller than field devices and routers. We consider that access point failures are included in the gateway; Repair rate: we considered repairs only when evaluating availability. Similarly to the failure rate, we assume a constant repair rate (µ). Although this could be an unrealistic assumption, it can be proved that this approximation results in small errors if the relationship µ λ is verified [19]. fd16 fd15 fd17 fd5 fd6 fd fd4 fd14 gtw fd7 fd1 fd13 fd3 fd2 fd8 fd12 fd9 fd1 fd11 Figure 6. Topology adopted in the evaluation process. As described in Section 2, the HCF provides three fundamental rules to design a WirelessHART network. Initially, we will evaluate the influence of the first two rules: rule of five and rule of three. The evaluation of the third rule is a consequence of the evaluation of the previous rules. The basic idea is to assess the influence of the rule of five upon the rule of three and vice-versa. The first problem that arises when trying to perform this type of evaluation is related to the adoption of a representative network failure condition (NFC) that can be useful to compare results obtained from different scenarios. Following the same principles that led to the use of a symmetrical topology, we adopted a pragmatic approach for their definition. Therefore, we define several NFC, each one is in the form K-out-of-N, where k is the number of field devices that must fail (k = 3, 6, 9, 12) and N the total number of field devices on the network (N = 14). In other words, we assume that the network fails if at least 3, 6, 9 or 12 field devices from the initial group of 14 field devices fail. This leads to 4 scenarios (note that the K-outof-N considers all combinations for each k).

7 5.2 Reliability evaluation In the following sections we present the evaluation of the network reliability considering the HCF rules. In order to facilitate the comparison between different scenarios we choose as metric the network MTTF. As previously discussed this metric is closely related to the reliability function. Note also that we don t consider any repairs in these scenarios Rule of five According to the rule of five, a WirelessHART network should have at least five field devices within the communication range of the gateway. For the evaluation of this rule it is necessary to eliminate some connections with the gateway neighbors and to measure its impact on the network. Initially we consider that there are only five neighbors in the topology presented in Figure 6. Due to its symmetrical nature, we can eliminate any connection between the gateway and its neighbors to guarantee the rule of five (note that only connections are eliminated, not devices). Other configurations are presented in Table 1. Table 1. Configurations used to evaluate the rule of five. Num. neighbors (gateway) Connections eliminated 6-5 fd gtw 4 fd gtw,fd 1 gtw 3 fd gtw,fd 1 gtw fd 2 gtw 2 fd gtw,fd 1 gtw fd 2 gtw,fd 3 gtw To measure the impact of rule of five we compute the network MTTF. Assuming that MT T F (j) is the network MTTF when the gateway has j neighbors, then the impact of rule of five can be given by: MT T F ratio = MT T F (j) MT T F (5) MT T F (5) (5) The results from rule of five are presented in Figure 7. Depending of the network failure condition, the influence of rule of five has different impacts. When the number of devices which leads to a network failure is small (e.g. 3 out 14 : 3/14), the influence of the number of neighbors is almost negligible. In this case the failure condition is mainly ruled by the number of operating devices and not by the number of paths to the gateway. On the other hand, when the number of devices that lead to a network failure is higher (e.g. 9/14 or 12/14) we observe the opposite behavior. That is, the number of communication paths has a stronger influence. Moreover, we can also verify that in the previous scenarios increasing to 6 (decreasing to 4) on the number of neighbors leads to an average increase (decrease) of 5% in the MTTF. However, when the number of neighbors is reduced to 3 or 2, the results show a significant reduction in the MTTF (in some cases 2% to 3%). As a conclusion, the results show that the rule of five can have a real impact on the MTTF of the network, in particular when the number of devices that are need to the network operation is just a small-medium fraction of the total, or when the number of neighbors is very small. In these conditions adding neighbors to the gateway could be an useful solution to guarantee the dependability requirements of applications. MTTF ratio (%) neighbors 4 neighbors 3 neighbors 2 neighbors Rule of three 3/14 6/14 9/14 12/14 Network failure condition k out n devices Figure 7. Rule of five evaluation. According to the HCF best practices, the rule of three indicates that every field device should have at least three neighbors. For the evaluation this rule we consider a topology according to the rule of five (gateway with five neighbors) and choose a target device which is not a gateway neighbor. After that, we eliminate some connections of the target device with their neighbors and measure its impact on the network. Considering the symmetrical property of the topology, the field device fd 13 was adopted as the target device in the evaluation process. Table 2 summarizes the configurations used in this evaluation. Table 2. Configurations used to evaluate the rule of three. Num. of neighbors (fd 13 ) Connections eliminated 4-3 fd 4 fd 13 2 fd 4 fd 13,fd 3 fd 13 1 fd 4 fd 13,fd 3 fd 13 fd 12 fd 13 Similarly to the rule of five, in the analysis of rule of three we use the network MTTT as the evaluation metric. Assuming that MT T F (j) is the network MTTF when the field device fd 13 has j neighbors, then the impact of rule of three is given by: MT T F ratio = MT T F (j) MT T F (3) MT T F (3) (6)

8 The results of rule of three evaluation are presented in Figure 8. Differently from rule of five, it is possible to distinguish the influence of rule of three for all network failure conditions. It is possible to observe that the results follow a curve with a unimodal behavior. The maximum relative impact occurs for the 6/14 scenario, decreasing the impact both to the left (3/14) and to the right (12/14), however for different reasons. When the number of devices which leads to a network failure is small (3/14), this factor has a major weight in the results than the number of neighbors. When the number of devices in the NFC grows (e.g. 9/14 and 12/14) the fact of a device has 1 or 2 neighbors becomes less important due to size of NFC. In general, the network MTTF decreases when the connections with the target device are eliminated. The reverse result is found when the connections are added. From this point of view, the rule of three and rule of five have the same behavior. For both rules, the impact to eliminate a neighbor is greater than add other neighbor. MTTF ratio (%) neighbors 2 neighbors 1 neighbor 3/14 6/14 9/14 12/14 Network failure condition k out n devices Figure 8. Rule of three evaluation Rule of 25% evaluation According to the rule of 25%, when the network grows, at least 25% of the field devices should be within the gateway communication range. To measure the impact of rule of 25% we can use the same evaluation process of rule of five. The idea is to consider that the number of gateway neighbors increases until the maximum number of field devices and measure the impact on the network. Note that we are not adding new devices, but just considering that the number of devices that are in the gateway range increases. The configurations used in the evaluation process are presented in Table 3. Table 3. Configurations used to evaluate the rule of 25%. Number of neighbors (gtw) Neighbors added 8 fd 6,fd 8 11 fd 6,fd 7,fd 8,fd 1,fd fd 6,fd 7,fd 8,fd 1,fd 12 fd 13,fd 14,fd 16 The results of rule of 25% evaluation were based on Equation 5. Figure 9 summarizes the results. As expected, the network MTTF increases when the number of gateway neighbors increases. However, increasing the number of gateway neighbors in real scenarios could be impracticable due to environment limitations (e.g. devices must be placed nearby the variables to measure). Anyway, this evaluation could be used to attain the dependability requirements of the applications. MTTF ratio (%) neighbors 11 neighbors 14 neighbors 3/14 6/14 9/14 12/14 Network failure condition k out n devices Figure 9. Rule of 25% evaluation. 5.3 Availability evaluation An additional evaluation of rule of three was performed using as metric the network availability. Since we are only interested in measuring trends, we consider the steadystate availability (t ). We assume a MTTR (Mean Time to Repair) equal to 2 hours, which is equivalent to a repair rate of µ.5 hour 1. The obtained results (not displayed) show that the changes in the steady-state availability of network are almost imperceptible, when the number of fd 13 neighbors varies (1 to 4 range). This behavior results from two factors: (i) the MTTR is several order of magnitude smaller than the MTTF; (ii) we assumed that there is always a repairman available. The combination of both factors leads to a very small downtime, and consequently the impact of this rule is negligible. In order to better understand the behavior of the network availability, we performed a sensitivity analysis assuming that the device fd 13 has 3 neighbors and the NFC configured to 6/14. We considered that the failure and repair rates of field devices varies in a range of values: the MTTR ranges between 1 and 24 hours, whereas the MTTF could be 5, 1 and 15 years. These are consistent values according to the industry practice. The results are presented in Figure 1. For the sake of understanding, results are described using the network unavailability (= 1 availability) in a log scale. As expected, the unavailability increases as the repair time increases. However, the impact of the MTTR is higher for lower values (e.g. < 5 hours). This means that the reduction of the MTTR only becomes worthwhile when it achieves low values (e.g. < 2 hours). The analysis of the MTTF indicates that the use of more reliable devices (1 and 15 years) results in a smaller difference considering the impact on the network unavailability. So

9 there is a limit to which it is not worthwhile to invest in more reliable devices (and more expensive). However the use of less reliable devices (e.g. MTTF=5 years) leads to a significant impact on the results. Network Unavailability.1 1e 5 1e 6 1e Repair time(h) MTTF = 15 years MTTF = 1 years MTTF = 5 years Figure 1. Network unavailability: sensitivity analysis. 6. Conclusions In this paper we have performed a reliability and availability evaluation of WirelessHART networks based on the rules indicated by the HFC. To conduct the evaluation we used a previously proposed methodology to evaluate the dependability of Wireless Sensor Networks. The results show that the best practices have different impact on the network. The rule of three has a larger coverage in the sense that its impact is distinguishable to any network failure condition. However, the rule of five have stronger impact on the network reliability. For both rules, the impact to eliminate a neighbor is greater than add other neighbor. As the network grows the rule of 25% becomes dominant. It was also observed that the MTTF of network is directly proportional to the number of gateway neighbors. The methodology proposed in this work can be used on any WirelessHART as an useful tool for network design and to evaluate other best practices that will arise. In future works we pretend to extend the methodology to consider the use of spare devices, hierarchical models for the availability computation, coverage factors related with the reconfiguration mechanisms and common-cause failures. References [1] Military handbook - reliability prediction of electronic equipment (mil-hdbk-217f). Technical report, United States Department of Defense, [2] IEC 62591: Industrial communication networks - Wireless communication network and communications profiles - WirelessHART, May 21. [3] H. AboElFotoh and C. Colbourn. Computing 2-terminal reliability for radio-broadcast networks. Reliability, IEEE Transactions on, 38(5): , dec [4] A. Avizienis, J.-C. Laprie, B. Randell, and C. Landwehr. Basic concepts and taxonomy of dependable and secure computing. IEEE Trans. Dependable Secur. Comput., 1(1):11 33, 24. [5] M. O. Ball. Computational complexity of network reliability analysis: An overview. Reliability, IEEE Transactions on, 35(3):23 239, aug [6] HCF. Wirelesshart - getting started. http: // wireless_getting_started.html, 211. [Online; accessed 3-December-211]. [7] W. Hou. Integrated Reliability and Availability Analysis of Networks with Software Failures and Hardware Failures. PhD thesis, University of South Florida, Department of Industrial and Management Systems Engineering, 23. [8] H. Kirrmann. Fault tolerance in process control: An overview and examples of european products. Micro, IEEE, 7(5):27 5, oct [9] N. Limnios. Fault trees. Control systems, robotics and manufacturing series. ISTE, 27. [1] A. Majdara and T. Wakabayashi. Component-based modeling of systems for automated fault tree generation. Reliability Engineering and System Safety, 94(6): , 29. [11] M. Malhotra and A. Reibman. Selecting and implementing phase approximations for semi-markov models. Communications in Statistics. Stochastic Models, 9(4):473 56, [12] M. Rausand and A. Hsyland. System reliability theory : models, statistical methods, and applications. John Wiley & Sons, Inc., Publication, 2 edition, 24. [13] R. A. Sahner, K. Trivedi, and A. Puliafito. Performance and Reliability Analysis of Computer Systems: An Example-Based Approach Using the SHARPE Software Package. Kluwer Academic Publishers, [14] T. Sauter. The three generations of field-level networks - evolution and compatibility issues. Industrial Electronics, IEEE Transactions on, 57(11): , nov. 21. [15] A. Shrestha, L. Xing, and H. Liu. Infrastructure communication reliability of wireless sensor networks. In Dependable, Autonomic and Secure Computing, 2nd IEEE International Symposium on, pages , oct [16] A. Shrestha, L. Xing, and H. Liu. Modeling and evaluating the reliability of wireless sensor networks. In Reliability and Maintainability Symposium, 27. RAMS 7. Annual, pages , jan. 27. [17] I. Silva, L. A. Guedes, P. Portugal, and F. Vasques. Reliability and availability evaluation of wireless sensor networks for industrial applications. Sensors, 12(1):86 838, 212. [18] J. Song, S. Han, A. Mok, D. Chen, M. Lucas, and M. Nixon. Wirelesshart: Applying wireless technology in real-time industrial process control. In Real-Time and Embedded Technology and Applications Symposium, 28. RTAS 8. IEEE, pages , April 28. [19] K. S. Trivedi. Probability and Statistics with Reliability, Queueing, and Computer Science Applications. Wiley- Interscience, 2nd edition, 21. [2] K. S. Trivedi and R. Sahner. Sharpe at the age of twenty two. SIGMETRICS Perform. Eval. Rev., 36:52 57, March 29. [21] G. Zhao. Wireless sensor networks for industrial process monitoring and control: A survey. Network Protocols and Algorithms, 3(1):46 63, 211.