Zigbee and Long-Range Architecture Based Monitoring System for Oil Pipeline Monitoring with the Internet of Things

Abstract

Oil pipeline monitoring is having a significant role in minimizing the impact on the environment and humans during pipeline accidents. The real-time monitoring of oil pipelines empowers the authorities to have continuous supervision of the oil pipeline. The Internet of Things (IoT) provides an opportunity for realizing the real-time monitoring system by deploying the IoT-enabled end devices on the oil pipeline. In this study, we propose a hybrid architecture based on 2.4 GHz-based Zigbee and LoRa communication for oil pipeline monitoring. Moreover, customized end devices and LoRa based gateway are designed and implemented for sensing the critical parameters of an oil pipeline. Here, we have performed the simulation of ZigBee communication on the OPNET simulator for evaluating the parameters such as packet delivery ratio (PDR), retransmission attempts, throughput, medium access (MAC) queue size, and queue delay. Furthermore, the distinct evaluation metrics of LoRa such as bit rate, link budget, and receiver sensitivity are also included. Finally, a real-time experiment is implemented with customized end devices and a gateway for evaluating the proposed architecture. In the real-time experiment, the devices and gateway are logging the pressure sensory data into the Cayenne cloud.

1. Introduction

The utilization of pipelines is recognized as a significant means of transporting petroleum products, such as gases, fossil fuels, chemicals, and other prominent hydrocarbon fluids that contribute to the nation’s economy [1]. The most affordable and secure way of transporting crude oil was realized with oil and gas pipeline networks, and they deliver the growing demand for quality and reliability [2,3]. As compared to pipelines, the reported deaths, the accidents caused during transportation of petroleum products are 2.7%, 4%, and 87% through rail, ship, and truck, respectively [4]. To overcome and avoid accidents through transportation, the pipeline is widely implemented globally for oil transportation. However, the wide implementation pipeline has increased the chances of pipeline failures [5]. According to PHMSA (Pipeline and Hazardous Materials Safety Administration), the hazardous line liquid incidents from the year 2010 to 2019 are 3978. The causes of these incidents are shown in Figure 1, while the year-wise pipeline failure incidents are addressed in

Table 1. Year-wise pipeline failure incidents.

Year	2010	2011	2012	2013	2014	2015	2016	2017	2018	2019
Incidents	340	344	366	401	455	460	420	415	405	362

.

Figure 1 illustrates the causes of oil pipeline failures and PHMSA identified three major causes of oil pipeline leakage namely: corrosion, pipe material, and hardware problems [6]. Corrosion is the major cause of oil pipeline failures. Moreover, external corrosion is galvanic corrosion and accounts for approximately 60% of these, whereas inside corrosion is mostly caused by microbial consumption [7]. The accidents and statistics related to the oil pipeline failure encouraged researchers to implement a monitoring and supervising system. Assessment of pipeline with integrity management systems, such as on-the-ground and aerial monitoring by security personnel are holding the major disadvantages in inspecting and monitoring pipeline due to high cost and complexity of design as well as the absence of suitable access routes. Historically, pipeline operators have struggled with real-time pipeline monitoring that is not limited to control rooms in a single place.

In previous studies, intelligence pipeline inspection gauges (PIGs) are implemented for monitoring pipelines. However, implementing this PIG requires a high amount of investment due to the length of the pipeline is about 2.5 km [8]. According to estimates, the cost of pipeline monitoring and inspection by pigs can reach USD 56,000 per kilometer. Companies spend close to USD 105 billion on pigging the world’s hydrocarbon pipelines although 25% of the world’s pipelines are “un-piggable”. The existing methods, which are proposed by distinct researchers, are classified into three categories, exterior methods, visual methods, and computational based methods [9,10,11]. However, the integration of all these methods with remote monitoring will assist the authorities to monitor the condition of pipelines from any remote location.

Remote monitoring is possible with emerging digital technology, i.e., IoT [12]. The IoT is an emerging environment that connects physical things to the digital environment with the assistance of the internet [13]. Moreover, advanced sensor and wireless communication technology are progressing day by day, encouraging the utilization of the IoT in various fields for remote and real-time monitoring [14]. Generally, the pipelines pass through the outer environment of the cities, so here IoT-based remote monitoring systems require a robust and reliable communication protocol that can communicate the data of the pipeline to a long range without any interruption. Here, the long-range (LoRa) communication is feasible for communicating the data to the long-range with minimum consumption. With this advantage, we have proposed a hybrid architecture for oil pipeline monitoring-based on 2.4 GHz-based Zigbee and LoRa communication. The proposed architecture enables to monitor the oil pipeline through the cloud server. Here we have developed and implemented customized end devices and gateway based on 2.4 GHz-based Zigbee and LoRa communication for oil pipeline monitoring.

The contribution of the study is as follows:

(a)

A hybrid architecture is proposed for real-time monitoring of oil pipelines using 2.4 GHz-based Zigbee and LoRa communication with a cloud server.

(b)

Customized detection end device, monitoring end device, safety operation controller, and gateway are designed and developed based on 2.4 GHz-based Zigbee and LoRa.

(c)

Zigbee simulation is performed on the OPNET simulator for evaluating the PDR, retransmission attempts, throughput, medium access control (MAC) queue size, and queue delay.

(d)

The distinct evaluation metrics of LoRa such as bit rate, link budget, and receiver sensitivity are also presented.

(e)

A Cayenne cloud is implemented for logging the pressure sensor value of the pipeline through the internet.

The structure of the paper is as follows: Section 2 covers the related studies and Section 3 covers the overview of Zigbee and LoRa communication. Section 4 covers the proposed architecture. Section 5 covers the hardware realization of the detection end device, monitoring end device, safety operation controller, and LoRa based gateway. Section 6 covers the simulation analysis of Zigbee and LoRa. Section 7 covers the experimental results with comparative analysis.

2. Related Studies

Remote monitoring in the oil pipelines enhances leakage detection and safety; in this section, we present the remote monitoring-based system for oil pipeline detection. Generally, remote monitoring assists respective authorities to have critical information regarding the health of pipelines. This indeed benefits authorities to respond in quick time for minimizing damage and loss of valuable oil that is transported from a far location. Initially, we present the traditional remote monitoring that is following by many industries, and later the significance of real-time monitoring with the IoT will be presented.

Remote monitoring is implemented with the assistance of a helicopter, smart pigging, autonomous underwater vehicles, and sensor networks [15,16,17,18]. In recent years, the remote knowledge estimation unit has been wirelessly transmitted to monitor and evaluate the process’s activities and make a knowledgeable decision in the case of a traumatic [19,20,21]. Automated control systems allow the stable and cost-effective operation of dynamic transport processes with the PID controller [22]. A continuous calculation of operative parameters such as heat, friction, level, flow, and focus and the creation of decisions for the opening or closure of a vapor, slowing up or speeding up a pump or raising or decreasing heat to maintain chosen process measurements in the fixed range values are achieved. Protection is the main vision for advanced control systems because manual loops have a sufficient output of only 68%; thus, the need for sophisticated smart surveillance and control in the latest scenarios is intensified to reduce optimum efficiency in the system [6].

Supervisory Control and Data Acquisition (SCADA) is the system that is the integration of hardware and software to follow activities namely: supervising the mechanism of the industrial process remotely or locally, obtain and process the real-time data, and records the activities into a log file [23]. Generally, in the SCADA system, the main components present are programmable logic controllers (PLCs) or remote terminal units (RTUs) [24]. PLCs and RTUs are two different digital computers that are integrated with the things such as sensors, Human-Machine Interface (HMIs) and it communicates the information of things to the main computer that is based on SCADA software. This software is capable of processing, communicating, and visualizing the data for assisting operators to take critical decisions [25]. However, the SCADA system requires a high-end infrastructure for remote monitoring, and also the deployment of PLC and RTUs occupies much space [26]. In SCADA systems, the authorities can receive information on the specialized system that is based on the software. The advancement in the sensors led toward the establishment of a wireless sensor network (WSN). WSN encourages to implementation of the wireless infrastructure for initiating communication between the physical things and remote servers. Generally, WSN technology is being used for oil extraction from the field in the upstream sector [27]. The mid-stream industry needs WSN technology to maintain critical pipeline parameters such as leak detection, corrosion, oil repair temperature, and gauge pressures. [28] WSN is implemented in the downstream sector in the procedure of refining and oil stock in wells [29,30]. The implementation of the automatic system for monitoring oil industries is generally based on WSN. However, real-time monitoring, analytics, and decision-making are limited in the WSN. The evolution of the IoT has provided an opportunity for researchers to apply it in real-time monitoring of the oil pipeline from any remote location without any human intervention [31]. The IoT is the interconnection of many networks through the internet. Here the physical things are monitored and controlled through the internet from anywhere. IoT-based devices capture the relevant data from the sensors and communicate it to the server through the internet. The IoT-based server is having the capability of performing analytics for taking critical decisions during a disaster [26]. WSN is a subset of the IoT, as WSN empowers the IoT to obtain the sensor data from the distinct physical things through a wireless communication protocol.

3. Proposed Architecture

The implementation of a real-time IoT-based monitoring system for oil pipelines is an emerging area. In real-time monitoring, the role of wireless communication protocol is crucial, because the sensory data need to transmit reliably and effectively. Generally, in many studies, the researchers have implemented the 2.4 GHz-based Zigbee and LoRa communication protocol separately for obtaining the sensory data from the oil pipelines. However, the implementation of the ZigBee communication protocol is only for short-range communication, so it is somewhat challenging to deploy multiple ZigBee sensor nodes for establishing a connection. The failure connection of a single sensor node during the establishment of the connection leads to complete connection failure. In case, the implementation of the LoRa network in every single node raises the infrastructure cost. To overcome all these challenges, a hybrid architecture is proposed for oil pipeline monitoring by integrating 2.4 GHz-based ZigBee, LoRa, and Wi-Fi communication and it is shown in Figure 2.

3.1. System Architecture

The architecture is the integration of these five different systems, namely: detection end device, monitoring end device, safety operation controller, drone yard, and the LoRa gateway as shown in Figure 2. The method implemented behind this work is based on the flow of the oil in the pipeline. Here, the ultrasonic flow sensor is mainly utilized for identifying the flow of oil in the pipeline. This sensor calculates the flow of the oil by calculating the time takes for sound to travel downstream and upstream. Moreover, the pressure sensor activates when the flow sensor identifies the passes of oil in the pipeline.

The proposed architecture illustrates that the detection end device and monitoring end devices are the two distinct nodes that are specifically embedded for monitoring the pipeline from inside and outside. These two nodes are positioned for the pipeline according to the requirement and infrastructure. The monitoring end device is utilized for sensing the critical parameters of the pipeline such as vibration, flow rate, temperature, humidity, and pressure. The LoRa communication protocol in the monitoring end device can communicate long-range, it enables the monitoring end device to communicate the critical parameter of the pipeline to the LoRa based gateway.

A detection end device is employed for detecting the corrosion, fire, leakage, and location, so with the assistance of ZigBee communication protocol, it sends the information to the safety operation controller unit. In case of any emergency, the hooter alerts the authorities and workers to act accordingly for reducing the damage and loss of life. Additionally, the monitoring end device is also integrated with the ZigBee communication protocol for receiving the sensory data from the detection end device and communicating it to the LoRa based gateway via LoRa communication. LoRa based gateway is an integration of LoRa and Wi-Fi module, so it communicates the sensory data received from the monitoring end device and detection end device to the cloud server. Cloud server visualizes the sensory data of both detection end devices and monitoring end devices from any remote location. This indeed assists authorities to visualize the data graphical user interface and record the data for enhancing the drawbacks that are identified through analytics.

In the proposed system, instead of sensing the present values of the individual sensors, our onboard algorithms evaluate the difference between the sensor parameters between the adjacent nodes. In case when the difference value obtained crosses a defined threshold set by the auto-configuring Kalman function, the system flags the involved nodes as a case of possible damage-prone. The same case is then verified by the values received from the consequent nodes and, if the same is confirmed, a confirmed damaged flag is initiated. The pressure monitoring is evaluated with the following mathematical model. The mathematical model behind this work is based on the pressure pulse generated from the pipe during damage. Here, the pressure pulse propagates in either direction from the locality of the damage and these pulses are reflected when they attain the edges of the oil pipeline. This work analyzed the vibration-based events of the oil pipeline by integrating the sensor on both ends of the event. The transmission duration of pressure pulses is calculated through pressure measurement sampling with maximum frequency at numerous sites along a pipeline. The arrival times of pulses in a pipeline and sensor placements along the pipe can be utilized to monitor a pipe and establish the location of an event. The events are established either due to penetrating or explosion, as shown in Figure 3.

Figure 3 presents the placement of the five-detection end device (D.N 1 to D.N 5) on the pipeline for detecting the location of the event. The distances are represented as D1, D2, D3, D4, and D5. The five sensors recording the arrival times of certainly produced pulses caused due to disruption explosive event originating at an unknown location are represented as t1, t2, t3, t4 and t5. Sensor 2 or 3 may be utilized to decide the location of the event on the pipe as shown in Figure 3. A damaging event on a pipe involves a shift in pressure within the pipe, which gradually resulting in the emergence of pressure pulses. Every change in pressure travels through the oil pipeline at a velocity C_p in the form of a pressure pulse in both directions. Here the pulse propagation velocity is calculated from the arrival pulses that are generated on the same end of the event through the sensors of D.N 2 and D.N 1 or D.N 3 and D.N 4. Finally, the precise location of the damage event is evaluated from the sensor of D.N 2 with Equation (1):

$$y_{DE2}=\frac{\left(t_{23C_p+D32}\right) }{2}$$

(1)

where $t_{23}$ indicates the time delay between arrival times of the sensor;

$D_{32}$ indicates the distance between sensor 3 and sensor 2;

$C_p$ indicates the velocity of pressure [$C_p=\frac{D_{pq}}{t_{delay ab}}$].

The precise location of the damage event is also evaluated from the sensor of D.N 3 with Equation (5):

$$y_{DE3}=\frac{\left(D32-t_{23C_p}\right) }{2}$$

(2)

3.2. Network Architecture

This section presents the mechanism of establishing the communication between the sensor nodes (detection end device) and coordinator (monitoring end device). Moreover, the communication establishment of sensor node and coordinator are also detailed presented. The security that is implemented in the network is also clearly presented, including interference of the communication network.

(a)

Communication:

In this section, we present the wireless link of the different components present in Figure 4. The wireless links are represented in the dash links and different colors are assigned to the dash links for recognizing the type of wireless communication. The black color dash line is for 2.4 GHz RF communication, and the red color dash line is for LoRa communication. A 2.4 GHz-based ZigBee communication module is available for detection of end devices and monitoring end devices.

In our study, we are aiming to utilize point-to-point communication for the implementation of the proposed system, where the sensor nodes (detection end device) only communicate with the corresponding allotted adjacent sensory node (detection end device). Moreover, a hopping data sharing mechanism is used, where the sensory node that is least distance from the coordinator (Monitoring end device) communicates all the data from the other nodes with the coordinator (Monitoring end device) which means that the node will be the single point of contact for the allotted sensory nodes with the coordinator as shown in the Figure 4.

As shown in Figure 5 of the proposed system, two communication modules were used, i.e., Zigbee and LoRa. Both the modules are chosen for their corresponding transmission properties suitable for the specific type of conditions and scenarios of application. For example, ZigBee (2.4 GHz) is more preferably used for data with lengthy packet sizes and applications requiring high data rate communication, while compromising the data communication distance limit. Similarly, LoRa (433 MHz in India) is preferably used for communication to longer distances while compromising the data size and length.

In our system, the main computing unit uses the integrated ZigBee module through UART communication protocol to collect data from local nodes deployed at nearby places with more immunity to data loss. It then processes the received data to clean and format it into suitable packets and then it uses the integrated LoRa module through SPI communication protocol to transmit the formed packets to an allotted gateway that is presumably deployed at a long distance from the node.

(b)

Security

During the deployment stage, we use AVR series of microcontrollers for applications similar to the current proposed one. In AVR using time complex or memory, complex algorithms are like a curse, because many times they convert the executing code into a blocking one which means during that process any other routine to be executed by the controlled is blocked and may cause interruptions in performing the desired function. Keeping these into considerations, we have to be very careful while using cryptographic algorithms in these low-bit controllers. Cryptographic functions such as AVR-Crypto, XXTea can be used for implementing encryption methodology. In our case, we have used the XXTea cipher functions for implementing symmetric encryption with private keys that remains unique for a different level of network nodes for enhanced security during data communication.

Similarly, every node has its unique identifier strings including “nodeId” and “preamble” which is always used by the nodes to ID themselves while checking their formatted packet strings separated by a specific delimiter such as:

String Data = nodeId + ‘:’ + preamble + ‘:’ + dataLength() + ‘:’ + data + ‘:’ + originNodeId + ‘:’ + endBit; + ‘/n’;

(c)

Interference

The standard parameter for detecting and thereby handling the interferences includes packet error rate (PER), bit error rate (BER), signal-to-interference-plus-noise ratio (SINR), Received Signal Strength Indicator (RSSI), Throughput, and time delay. In this study, we have applied a frequency agility-based interference avoidance algorithm. This algorithm enables the ZigBee to detect the interference and flexibility to shift the nodes to a safe channel with minimum energy consumption and latency during handling interference. In this algorithm, the end devices measure PER with a transmission period of at least 20 packets and if the PER exceeds the 25% level, the interference information is communicated to the parent router to evaluate the link quality indicator (LQI). Here, the parent router identifies that the LQI value is less than 100, then it directs to perform interference detection of available channels by scanning energy detection (ED). The PER is calculated with the following Equation (3):

$$PER=\left(\frac{Number of failed messages}{Number of attempted measurements}\right)\ast 100\%$$

(3)

Other than this, all of our nodes in the network have their unique ID parameters such as nodeId and preamble. All nodes only communicate if the ID parameters included in the received string from the other node trying to communicate have all the ID parameters valid. Otherwise, the communication is rejected and ignored. This allows the system to make sure that only the nodes that are allotted to them or are desired to communicate can communicate with each other.

4. Hardware Design

In this section, we will discuss the significance of customizing the nodes and gateway for the required application. The customization assists the researchers to utilize the nodes according to their requirements. In the initial stage of the customization, the primary parameter that needs to be considered is power consumption, because the sensor nodes are placed at such a location where the additional electrical system is a bit challenging. So, the components which are chosen for the customization need to be low power. With concern to low power, we have chosen the LoRa communication protocol for the sensor node, as it delivers long transmission with low power consumption, and we have chosen 2.4 GHz-based ZigBee for communicating the data to the short-range activities. SX 1278 based LoRa module is utilized in our sensor node and its operating voltage is around 1.8 V to 3.6 V.

Another main component of to design node is the controlling unit. The controlling unit in the node is utilized for processing the acquisition data and alerting the communication unit to send the sensory information. Here we have chosen the Atmega 328P microcontroller, as it is low power 8-bit microcontroller that is based on reduced instruction set computer (RISC) architecture. This controller comprises 6 analog and 14 digital pins with an operating voltage range of 2.7 V to 5.5 V. As we can observe that the SX 1278 based LoRa and Atmega 328P microcontroller is having different operating voltages, however, the voltage converter in the circuit of the sensor node converts the appropriate voltage. After the completion of selecting appropriate components for designing the node, the next stage involves assembling all of these components on a single board to execute a scalable, stable, and compatible node. The following are the block diagram, printed circuit board (PCB) layout, and hardware prototype of the detection end device, monitoring end device, safety operation controller, and LoRa gateway.

(a)

Monitoring End device section

The monitoring end device senses the critical parameters of the pipeline. 2.4 GHz-based Zigbee and LoRa are integrated for communicating the multiple tasks data of the pipeline as discussed in the above section. Due to external heating of heavy oil transportation, the temperature of oil in the pipeline should be monitored. The gauge pressure of inflow and outflow of a pipeline should be measured. To find the third-party damages vibration of pipeline detection is necessary. Flow rate is the number of liters per specific time is transported to be monitored. Figure 6a presents the interfacing of the different components. Figure 6b presents the PCB layout of the monitoring end device, where it presents a schematic view of the final prototype. Figure 6c presents the final hardware prototype of the monitoring end device, where the design and size of the prototype revealed that it can be positioned in the pipeline with minimum space.

(b)

Detection End device

The detection end device senses the various environmental parameters of the pipeline. 2.4 GHz-based ZigBee is integrated for transmitting the sensory data to the monitoring end device and safety operation controller, as discussed in the above section. Corrosion is a major issue during oil pipeline transportation. So, detection of internal and external corrosion is very essential. Leakage for a pipeline is a common issue, but in oil transportation in the pipeline, if leaks happen, it creates environmental issues and human loss. So, detecting and locating the leaks is mandatory. Figure 7a presents the interfacing of the different components. Figure 7b presents the PCB layout of the detection end device, where it presents a schematic view of the final prototype. Figure 7c presents the final hardware prototype of the detection end device, where the ZigBee communication protocol is visualized along with a liquid crystal display (LCD).

(c)

Safety Operation controller

A safety operation controller is a unique system that is integrated into the proposed architecture. In case of any abnormal issues such as fire emission, corrosion and leakage, the signal will be received through a 2.4 GHz-based ZigBee protocol from the detection end device. To alert the authorities, a hooter with a driver is integrated on the board. It consists of a power supply circuit where supply is given to wireless RF controller and hooter driver and hooter, as shown in the Figure 8a. Figure 8b presents the PCB layout of the detection end device, where it presents a schematic view of the final prototype. Figure 8c presents the final hardware prototype of the safety operation controller, where the hooter, ZigBee, and controller are visualized.

(d)

LoRa based Gateway

In this study, the LoRa based gateway is implemented for communicating the real-time data of the monitoring end device and detection end device to the cloud server. This gateway is integrated with LoRa and Wi-Fi module for initiating the communication between the end devices and cloud server. If any abnormal issues are received from the end devices, then the gateway triggers the alarm with the assistance of the alarm driver interfacing with the controller board of the gateway and it is shown in the Figure 9a. As discussed earlier, the gateway is embedding with two different communication protocols, and it can be visualized in the PCB layout in the Figure 9b and also in the hardware prototype that is presented in the Figure 9c.

5. Simulation Analysis

In this section, we present the simulation of the Zigbee and LoRa networks. Here we have varied certain parameters to check the network behavior of both networks. OPNET simulator is utilized for performing the simulation. The simulation of the Zigbee and LoRa network is as follows:

5.1. Zigbee

Zigbee is IEEE 802.15.4 based wireless communication protocol that creates a personal area network (PAN) with low energy consumption [32]. Zigbee enhances the battery life of the end devices as it consumes low energy during data transmission. Figure 10 presents the ZigBee architecture where it consists of four distinct layers and they are named as physical layer, medium access control (MAC) sub-layer, network (NWK) layer, and application layer (APL) and is shown in the Figure 10 [33,34].

PHY layer is next to the hardware, and it controls and communicates directly over ZigBee radio. The PHY layer converts the data packets into over-the-air bits during transmission, and vice versa for the reception. MAC layer interfaces the PHY and NWK layers and it also generates a personal network identifier (PAN ID). MAC layer is responsible for network discovery through beacon requests. NWK functions as an intermediary layer between MAC and Application Layers. Furthermore, it manages the mesh networking, i.e., network establishment and routing. Additionally, the NWK Layer protects ZigBee networks by encrypting all data in the NWK Frame. The topmost protocol layer in ZigBee’s stack is the application layer, where it comprises ZigBee device objects (ZDO), and the application support sub-layer (APS). Moreover, the manufacturer-defined application objects are parts of the application layer. ZDO is a program that manages and gathers information about a system. The APS sub-layer provides a generic set of services that are utilized by both ZDO and the manufacturer-defined application objects for enabling an interface between the NWK and APL.

ZigBee is quickly expanding the field of The IoT allowing for more efficient wireless sensor-to-machine and machine-to-machine communication. ZigBee is used in industrial monitoring and actuators, home automation, medication, remote sensing, acoustic detection, and smart energy management, among other applications [15,17]. Advancements in space communication and monitoring system using WSN and ZigBee is analyzed [18]. The ZigBee network is made up of three components, namely: ZigBee routers, ZigBee end devices, and a ZigBee coordinator.

ZigBee end device: The end devices are primarily responsible for a ZigBee network’s power-saving features. Because these nodes are not used for traffic routing, they can sleep for the majority of the time, extending the battery life of these devices. Zigbee coordinator: This node is in charge of setting up the network, choosing the suitable channel, and allowing other devices to connect to it. In a ZigBee network, it can also be in charge of traffic routing. Zigbee Router: A router can send and receive messages in a network, as well as a link to child nodes, which could be another router or an end device. Figure 11 shows the packet structure employed for communication between transmitter and receiver.

Figure 12 depicts the ZigBee framework’s working model, in which various network nodes transmit data to the ZigBee coordinator via routers. The simulation was supposed to run for a specific amount of time using the network layer and physical layer characteristics listed in

Table 2. Parameter of Zigbee configuration.

Network Layer Parameters
Parameter	Value
ZigBee end device	12
Zigbee router	4
Zigbee coordinator	1
Packet size	1024 bytes
Packet interval time	Constant (1.0)
Physical Layer Parameters
Parameter	Value
Transmission band	2.4 GHz
Transmission Power	0.05W
Receiver Sensitivity	−85

.

In this solution, network traffic was formed using those parameters based on the device to coordinator settings. The ZigBee network model’s OPNET simulation is tested for examining various network performance indicators. Sent and received traffic statistics, the end-to-end delay between layers, packet delivery ratio, retransmission attempts, and throughput over the channels are all performance parameters of the application and MAC layers.

(a)

Packet delivery ratio

One of the most important performance metrics is the Packet Delivery Ratio (PDR). For all end nodes, the average packet delivery ratio is utilized. The ratio between the total number of data packets received by the sink and the total number of data packets transmitted by all end nodes can be determined. The data traffic is sent on average of 3500 bits/s from each node for the simulation period of 1600 s, i.e., around 42,000 bits/s send by all nodes in the network. Now the data traffic received by the coordinator is an average of 38,000 bits/s. The PDR value is nearly 0.90. In other words, the ZigBee coordinator receives 90% of data packets received correctly. Packet delivery ratio is expressed in Equation (4) as:

$$\mathrm{PDR}=\frac{D{P}_R}{D{P}_{TN1+D{P}_{TN2+-----D{P}_{TNn}}}}$$

(4)

where DP_R is no of data packets received, $D{P}_{TNn}$ is no of data packets sent by ‘N’ nodes.

(b)

Retransmission Attempts

The overall amount of retransmission tries made by all 802.15.4 MACs in the network until a packet is successfully sent or the attempt limit is reached. The retransmission attempt is 0.5 packets for the simulation period of 1600 s.

(c)

Throughput

Throughput refers to the rate at which data is successfully transmitted from a source node to a destination node. Here highest throughput is reached 50 kbps at starting time of simulation and it shows minimum level throughput is 40 kbps at 250 s. The average throughput carried is 45 kbps.

(d)

Queue Size and Queuing Delay

The total number of packets outstanding in the MAC queue is represented by the queue size. This is the number of requests in a queue that are waiting to be executed. The average queuing size is displayed in the Figure 13a is 0.5 packets which are considered very less. The queuing delay is the time it takes for packets from the network layer to reach the MAC queue and be executed. It is the most significant contributor to overall network latency. Figure 13b indicates that the queuing delay was about 0.03 s at the start of the simulation cycle, but it was significantly reduced to 0.01 s at the 200-s simulation time. Furthermore, the delay has been reduced to almost zero and has remained constant until the end.

(a)

End-end delay

The time it takes packets to propagate from the source to the destination is known as delay in wireless networks. It is made up of the total time spent on route finding, queuing, propagation, and transfer time. Figure 14 represents end-to-end delay at various simulation timings. The final results of the Zigbee simulation are clearly illustrated in the

Table 3. Simulation results.

Parameter	Average Data
Queuing size	0.5
Queuing delay	0.01 s
Throughput (bits/Second)	45,000 bits/s
Retransmission Attempts (Packets)	0.5 packets
Packet Delivery ratio	90%
End-to-end delay (Sec)	0.013 s

.

5.2. LoRa

LoRa is a communication protocol that uses a spread-spectrum technique and this protocol utilizes unlicensed ISM groups, i.e., 433 MHz in Asia, 868 MHz in Europe, and 915 MHz in North America [36]. The consequent signal has low noisy levels, engaging high check adaptability, and is difficult to stick or recognize [6]. Some works highlight the LoRa innovation and detailed data about LPWAN innovation and the PHY layer are represented by different parameters such as Code Rate (CR), Bandwidth (BW) Spreading Factor (SF), and Transmission power. Further, messages transmitted using particular spreading components can be gotten simultaneously by LoRa base stations [37]. LoRaWAN offers bi-directional availability over multi-kilometers go and with a bit rate between 0.3 kbps to 50 kbps. The frequency in the spectrum band is presented as BW, and it is selected from one of three bands: 125 kHz, 250 kHz, & 500 kHz. A large bandwidth indicates faster transmission while a small bandwidth denotes long-distance transmission. The key parameter of the LoRa modulation is BW.

The 2^SF chirps that comprise the complete frequency band are symbolized as the LoRa symbol. At first, it commences with a series of upward chirps; if the highest frequency band is attained, then the frequency is covered and there will be an increase in the frequency yet again from the lowest frequency. Bit Rate/data rate is defined as the rate at which bits are transferred from one location to another location. The bit rate (Rbit) of LoRa is expressed as:

$$Rbit=\frac{SF\ast BW}{2^{SF}\ast BW}$$

(5)

Sensitivity refers to a system’s capacity to extract information from signals. It may also be measured as the lowest feasible signal strength that will cause the system to packet resolution. The first term is generated by thermal noise in 1 Hz of bandwidth and can only be controlled by adjusting the receiver’s temperature. The receiver bandwidth is denoted by the second term, BW. NF is the noise figure of the receiver and is fixed for certain hardware implementation. Finally, SNR denotes the signal-to-noise ratio demanded by the underlying modulation strategy. The signal-to-noise ratio (SNR) and bandwidth are the design factors accessible to the LoRa designer. The LoRa receiver sensitivity (S) is calculated as follows:

$$S=-174+10{\mathit{log}}_{10}BW+NF+SNR$$

(6)

where S = receiver sensitivity in dB, BW = Bandwidth in KHz, NF = Noise Figure of a receiver in dB, and SNR = Signal-to-Noise Ratio.

A link budget, also known as received power, is the total of all losses and gains from the transmitter to the receiver over free space [32]. The link budget can be calculated by adding transmitter power (PT_x), receiver sensitivity (R_x), antenna gain, and free space path loss (FSPL). The link budget is expressed as:

$$P{R}_X=P{T}_X-FSPL+G{T}_X+G{R}_X$$

(7)

where $P{R}_X$ implies received power or link budget (dBm), $P{T}_X$ implies transmitter power (dBm), $G{T}_X$ implies transmitting antenna gain (dB), $G{R}_X$ implies as receiver antenna gain (dB), and FSPL implies free space path loss (dB).

The behavior of the network is evaluated by varying certain parameters such as SF, bandwidth, and CR. The analysis of bit rate, link budget, and LoRa sensitivity are presented below:

(a)

Bit rate:

The data rate/bit rate is well-defined as the number of bits that are transported during transmission between transmitter and receiver. We utilized Equation (5) for calculating the bit rate of the LoRa. To compute the bit rate of LoRa, the input parameters, such as SF, BW, and CR are included in the equation. Figure 15 presents the bit rate of LoRa from SF 7 to SF 12. BW8, BW9, and BW 10 are represented for 125 kHz, 250 kHz, and 500 kHz. The bit rate is represented in bits per second (bps). It can be observed that in every SF, the bit rate is eventually high at the BW 10 (500 kHz) and CR1. It can be observed that an increase in the SF7 is inversely affected by the bit rate, as the bit rate drops progressively from SF 7 to SF 12. In SF 7, the bit rate of the LoRa met 22,000 bps and in SF 12 the bit rate is limited to 2000 bps. An increase in SF will lead to communicating a low amount of data during transmission, so SF 7 is the optimal SF that needs to be considered for sending a large amount of the data.

(b)

Link budget:

Link budget or received power is the sum of the losses and gains. The concept of the link budget. To calculate the link budget, we considered Equation (7). In this study, the three BW, namely 125 kHz, 250 kHz, and 500 kHz, along with SF 7 & SF 12 are considered for calculating the link budget. The bandwidth is represented as BW1 (125 kHz), BW2 (250 kHz), and BW3 (500 kHz). 2 dBm, 5 dBm, 8 dBm, 11 dBm, and 14 dBm are the transmission power. The increase in the T_x is leading to an increase in the link budget, and it can be observed in Figure 16a. Every increase in the SF causes an increase in the link budget. The link budget attained maximum dBm for 125 kHz of SF 12 at 14 dBm. The link budget detected a low dBm for 500 kHz at SF7 of 2 dBm. It is observed that high T_x power and low BW achieve are feasible parameters for attaining the highest link budget.

(c)

Receiver sensitivity:

The BW, SF, and noise figures are the input parameters used for calculating the receiver’s LoRa sensitivity. Equation. 6 is employed for calculating and also BW of 125 kHz, 250 kHz, and 500 kHz are considered along. This BW is represented as BW1 (125 kHz), BW2 (250 kHz), and BW3 (500 KHz) respectively. The Signal-to-noise ratio (SNR) value is different for distinct SF. The following SNR are considered for SF 7 is −7.5, SF 8 is −10, SF9 is −12.5, SF 10 is −15, SF 11 is 17.5, and SF 12 is −20. Generally, power sensitivity has a negative number i.e., −127 dBm, here the value beyond that number implies that it is decreasing. Figure 16b presents the sensitivity from the SF 7 to SF 12; the sensitivity power is highest for the SF 7 at the BW3 (500 kHz), and the lowest sensitivity is observed for the SF12 at the BW 1 (125 kHz).

6. Experimental Results

This section covers the deployment of the proposed hybrid architecture for monitoring oil pipelines. Here, we have deployed the detection end device on the pipeline for sensing the critical parameters of the oil pipeline, i.e., pressure as shown in Figure 17. In this study, the sampling rate for transmission of the data of oil pipeline between the two-node is preset to 15 s. Moreover, the Zigbee and LoRa transmit data rates at the same baud rate in serial communication. The same has been embedded in the devices during the firmware development. Monitoring end device act as the coordinator node for all the detection end devices. To record the pressure sensor value, we have utilized the cloud and The IoT enable Cayenne application programming interface (API). To obtain Cayenne API and initiate sending and receiving the data we have uploaded the Cayenne MQTT ESP8266 Library in the gateway.

Moreover, we have created the Cayenne account through [38]. After creating the account, a new device is created for visualizing the sensor data in the Cayenne dashboard as shown in the figure. The API key of the new device in the Cayenne account is utilized for accessing and visualizing the data from mobile and web applications by individual authority.

In the experiment, the five detection end devices are deployed on the different points of the pipeline with the 100-m distance between two end devices for continuous sensing the pressure value. To measure the pressure value, the pressure transducer is embedded with detection end devices. As discussed in the architecture section, the detection end devices communicate the sensory information to the monitoring end device through 2.4 GHz-based Zigbee RF communication.

As a monitoring end device integrating with 2.4 GHz-based Zigbee RF communication and LoRa communication, it transmits the sensory data to the gateway. The gateway is the amalgamation of two different communication protocols, namely: LoRa communication and ESP 8266 Wi-Fi module. The received RF packets of sensory data are converted into internet protocol (IP) packets for sending to the cloud server through internet connectivity.

The experimental setup shown in Figure 17 is implemented in real-time in the pipeline. Figure 18 illustrates the setup of the detection end device, monitoring end device, and safety operation controller. Figure 18a shows the position of the detection end device on the pipeline with a solar-powered; Figure 18b shows the safety operation controller with alarm is positioned at the nearby controller authority based on 2.4 GHz ZigBee communication. Figure 18c presents the position of the flow meter and a pressure sensor for monitoring the flow rate and pressure on the pipeline. Moreover, the gateway is positioned at a location where the internet connectivity is good. From the gateway, the data of the pipeline such as pressure and flow meter are logged in the Cayenne cloud server.

As discussed above, the Cayenne-based cloud is utilized for recording and visualizes the sensory value from the detection end devices. The Figure 19 presents the Cayenne dashboard that visualizes the sensory value that is receiving from the detection end devices. In the Cayenne dashboard, we have denoted detection end devices as “Node” and the five detection end devices are represented as Node0, Node1, Node2, Node3, Node4, and Node5.

The unit of pressure values that are visualized in the Cayenne dashboard is Kilonewton per square meter (kN/m²). Figure 19 of the Cayenne dashboard ‘1’ displays the pressure value of the pipeline from the different detection end devices. Here, the threshold value for the pressure sensor is preset to the 1600 kN/m², if the sensor value is going above and below this threshold value reveals that the pressure value needs to be carefully inspected by the authorities. The dashboard displays the pressure values of the pipeline that remain constant from the different points.

Figure 20 of the Cayenne dashboards ‘2’ displays the pressure value of the pipeline from the different detection end devices. The dashboard displays the pressure values of the pipeline, where it can be an observer that the pressure value of Node0 and Node1 is constant. However, the pressure of the pipeline at three different points is reducing below the threshold value. The pressure value visualizes in the dashboard concludes that the pressure is decreasing drastically in Node2, Node3, and Node4. The pressure value of Node2 was reduced to 1000 kN/m², Node3 reduced to 800 kN/m² and Node4 reduced to 500 kN/m². The pressure value in node 2, node 3, and node 4 indicates that the amount of pressure is low when comparing with the threshold value. Moreover, it indicates that the pressure is low, and it needs to be carefully identified. These results on the cloud server assist the authorities in identifying the point at which the pressure is reducing from the different points.

The results are addressed in the Figure 19 and Figure 20 provide the status of the pressure inside the pipeline. In case if the pressure of the pipeline is high i.e., above the threshold level, then the detection end device sends the alerts to trigger the alarm in the safety operation controller for minimizing the damage.

Table 4. Comparison of our study with previous studies.

Research	Objective	Communication	Customized Node	Customized Gateway	Simulation-Based Analysis	Monitoring Critical Parameters	Remote Monitoring
[25]	Oil pipeline system to prevent crack during transportation online	PLC communication	Not implemented	Not implemented	Not performed	Flow, pressure	SCADA is implemented as a remote monitoring system
[39]	WSN & IoT-enabled system for monitoring oil	Implemented short-range RF communication	Not implemented	Not implemented	Not available	Vibration, Flow & pressure	Not available
[40]	IoT-based system monitoring the parameters of oil tanks	XBee S1 pro	Only proposed transmitter & receiver node	Serial communication is implemented for communicating data to the cloud server	Simulation not performed	Fire, temperature & humidity	Cloud-based Thingsspeak server is implemented for remote monitoring
[41]	Measurement nodes can collect information using IoT technology, which will subsequently be sent to the aggregate node	2.4 GHZ	No	No	Network simulation is not implemented	Temperature, pressure	A server is designed and implemented for remote monitoring
[42]	LoRaWAN based oil leak detection system	LoRaWAN	Implemented the sensor node that is readymade	Not customized but LoRaWAN gateway is implemented	NA	Flow, pressure & temperature	Thingspeak server is for remote monitoring and analytics purpose
[43]	Detection and mitigation of pipeline failures	LoRaWAN	Customized Sensor node not implemented	Gateway is not available	NA	Not mentioned	A cloud server is not implemented
[44]	real-time pipeline monitoring and determine the location of the damage on a pipeline	Wi-Fi	The Arduino-based module is implemented. Customization is not implemented	Gateway is not implemented. The data is communicated with a Wi-Fi-based Arduino module	NA	Propagating Pulses	Thingspeak server is for remote monitoring and analytics purpose
Proposed work	Hybrid architecture for real-time oil pipeline monitoring	2.4 GHz-based Zigbee and 433 MHz based LoRa	Customized sensor node with 2.4 GHz-based Zigbee and LoRa module	LoRa and ESP 8266 Wi-Fi module is integrated for customizing gateway	Zigbee and LoRa simulations are performed	Pressure and flow meter in real-time	IoT-based Cayenne is implemented for remote monitoring of oil pipeline

illustrates the comparison of previous studies with the proposed work. The comparison is done based on certain parameters that are illustrated in Table 4. The proposed study is having designed customized detection end device for monitoring the critical parameters of the oil pipeline such as vibration, flow rate, temperature, humidity, and pressure. Moreover, a monitoring end device acts as the coordinator node for the detection end device. A customized gateway is also developed and implemented. A hybrid architecture based on 2.4 GHz and LoRa communication is implemented in this study for oil pipeline monitoring. OPNET simulator is utilized for performing the simulation of ZigBee. With bit rate, link budget, and receiver sensitivity by varying the CR, BW, and SF. Generally, the implementation of customized sensor nodes and gateway are missing in the previous studies. Additionally, in The IoT’s implementation, Zigbee and LoRa communication are utilized separately for oil pipeline monitoring. The simulation of ZigBee for oil pipelines is also not addressed in the previous studies. Moreover, the real-time implementation of IoT-based devices is not implemented as in our study we have implemented with IoT-enabled Cayenne server. Finally, the pressure sensor data is receiving in the Cayenne server. The critical monitoring parameters component is included in the Table 4 for discussing the studies that are monitoring the critical parameters of the pipeline such as temperature, humidity, pressure, flow, vibration and, propagate pulses.

7. Conclusions

Oil pipeline monitoring is crucial for enhancing safety and minimizing the effect on humans and the environment. The advancement in sensor and communication technologies encourages implementing the IoT as a real-time monitoring system. With this advantage in this study, we have proposed cloud-enabled hybrid architecture based on 2.4 GHz-based Zigbee and LoRa communication The detection end device is the primary node for collecting the critical parameters information of pipeline and monitoring end device based on 2.4 GHz-based Zigbee and LoRa communication communicates the sensory information received from detection end device to the gateway through LoRa. The system is deployed in real-time for evaluating the proposed system, where the proposed system is logging the pressure sensor values on the Cayenne cloud server through the internet from the gateway. A simulation is performed for evaluating the network performance of LoRa and Zigbee. In future work, we will implement the IoT-based drone-enabled vision system for monitoring the pipeline in real-time.