Typesetting
in Ingeniería Solidaria
Multilayer validation system for the automation of data in a WSN network with IOT devices
Abstract
Introduction: This article resulted from the research “Multilevel validation system emphasized on data transmission in a Gateway for the IoT.” This write-up is supported by the Applications Over Internet Research Line of the Universidad Del Cauca during 2020.
Problem: Bridges between wireless sensor networks (WSN) and the Internet are necessary for an IoT devices’ operation. However, these networks are made up of weak links that can generate packet loss.
Objective: Present an alternative to improve the data transmission validation process in a previously developed WSN-IoT system.
Methodology: Implementation of the test-driven development methodology (TDD) for the buildout of validation application algorithms. The mentioned outcome was developed in the Android Studio®. This is also considered by the scientometric review on concepts related to Industry 4.0 (data from 2015 to 2019), IoT, and WSN (data from 1990 to 2019).
Results: A validation application that captures and analyzes data frames, in addition, compares the values of the monitored variable in each layer of the implemented model. Furthermore, the development reports the errors detected in the data transmission.
Conclusion: Upon completing this work, the WSN-IoT tracking system’s validation process was automated.
Originality: Through this research, the development of a Sniffer-type application was exposed for the first time. It allows for automation of the data transmission validation processes during the supply chain. It happens by monitoring each of the communication levels of the WSN-IoT system.
Limitations: There is little research in the area of validation. Hardware devices are few and delicate. In addition, there is a high dependence on networks to monitor the performance of the designed application.
Main Text
1. Introduction
For the correct functioning of the Internet of Things (IoT), the IoT Gateway bridges are necessary between the wireless sensor networks (WSN) and the Internet. This facilitates the perfect integration of different sensor networks and the diversity of protocols in WSN networks. However, these networks are made up of weak links that can generate a significant loss of data packets. This packet loss is usually caused by wireless link quality, node failures, congestion, and wireless medium transmission errors. Reducing packet loss helps to improve link bandwidth, performance, reliability in data delivery, quality of service (QoS) parameters of the network, and avoid delays in communication. To achieve the proper functioning of a WSN-IoT system, the research focused on the industrial area using logistics context. The purpose is to carry out traceability by tracking packages sent through various modes of transport. These packages have various types of load monitoring different variables (temperature, humidity, shock, vibration, inclination, and proximity) by collecting data with a set of sensor nodes called Tags. Their process is to store the data until a connection is made with a Gateway. The message with data is packed, modulated, applied, and transmitted to the Gateway. The data is transmitted through a short-range transmitter, named a Low-Rate wireless personal area network (LR-WPAN), at 2.4 GHz. Later, this Gateway loads the data to the cloud enabling remote monitoring, visibility, and greater operational efficiency.
To solve errors in the sensed data transmission, arises the need for new validation methods and experimental tools to study WSN networks with smart objects in real-time. Consequently, this document aims to present an alternative to improve the data transmission validation process given a frame implemented in a WSN-IoT system.
2. Literature review
Industry 4.0 is directly related to smart factories [1], with its automation through the exchange of data between logistics and the supply chain [2]. This encompasses companies that implement multiple concepts such as IoT and the Industrial Internet of Things (IIoT), as well as different technologies to increase their production processes and improve their competitiveness in the market, automating the interconnection of systems through the union of digital and physical systems [3,4]. Different investigations have been carried out in Industry 4.0. Among the most cited are the implications of Industry 4.0 in logistics [5], a review on human-centered smart tags connected to IoT for Industry 4.0 [1], a sustainable supply chain review for Industry 4.0 requirements [6], and an investigation into the focus on the Lean Six Sigma quality control method for global supply chain management [2]. This concept has been applied to smart industries (Smart Industry) [7] and smart steel inventory tracking with IoT / RFID [8].
The IIoT refers to the interconnection between machines, data, and people in the industry [9, 10]. This concept has been applied in smart labels for the industry [1], in Blockchain [11], in a cyber-physical system based on fog computing (Fog Computing) [12], in a real-time monitoring service based on IIoT for managing agri-food logistics [13], in an algorithm for supply chain management [14], in the monitoring of air quality in a logistics shipping base [15] and in intelligent monitoring of the steel inventory with IoT / RFID [8].
The supply chain comprises suppliers, manufacturers, warehouses, retailers, transporters, and consumers [16]. This system has been implemented in different areas such as security [17,18], cybersecurity [19], Blockchain [16], and fog computing for the automation of tasks in Industry 4.0 [12]. The objective of logistics in Industry 4.0 is to control the stages of the supply chain, where the different materials of a product intervene and the information related to it throughout its life cycle, as well as the supply of materials, storage, distribution and transportation of the product to the end user [20]. Different investigations have been carried out on this topic, such as a study on the implications of Industry 4.0 in logistics [5], an integration of the arrowhead framework in Logistics 4.0, an identification of the different impacts generated by changes in Industry 4.0 in logistics and supply chain management [21], and an estimation of service quality in industrial IoT monitoring applications [22].
Traceability is the set of processes that monitor and control a product within the supply chain by implementing technological tools. The monitoring is carried out in each stage, from the initial monitoring of the raw material to the product distribution [23]. To carry out this set of processes requires the participation of different technologies such as robotics, Blockchain, augmented reality, or cyber- physical systems [24]. Traceability has been applied in a real-time monitoring service based on IIoT to manage agri-food logistics [13], in the quality of service for industrial IoT monitoring applications [22], and the use of smart labels for Industry 4.0 [1].
Figure 1 shows the number of documents in the WOS and Scopus databases for each concept (IIoT, Industry 4.0, supply chain, Logistics 4.0, traceability, and M2M). The Y-axis represents the name of each topic, the X-axis the total number of documents by topic, and the orange color the percentage of documents published in the last year (2018-2019). The graph shows that the concepts with the most significant trend are IIOT and Industry 4.0 as these have the highest percentage of documents published in the last year (2018 - 2019) with 90% and 82%, respectively. However, the other concepts also have a high percentage (greater than 50%). In the same way, Figure 2 presents all the documents downloaded from the Web of Science (WoS) and Scopus databases and the percentage of duplicate documents deleted. The ScientoPy tool maintains a WoS documents’ priority over Scopus documents, so fewer documents are observed in Scopus.
Figure 3 makes a comparison between the growth of IoT and WSN in the WoS and Scopus databases. The Y-axis represents the number of articles published per year, the X-axis the timeline (1998 to 2019), the blue color the published documents dealing with WSN, and the orange color the published documents dealing with IoT. The investigations on WSN began in 1998. These start with an article about collision resolution techniques for random slotted access wireless networks [25]. WSN continues with a period of non-linear growth until 2011 remains almost stable until 2019. However, IoT research began in 2006 with an article that stated that it is a paradigm. Theirs have an architecture that allows the objects to communicate by exchanging information over the Internet [26].
The term WSN began to be implemented around 1980 in the project “Distributed Sensor Networks” (DSN) of the Defense Advanced Research Projects Agency (DARPA). The term IoT was publicly presented around 2009 by Professor Kevin Ashton of the Massachusetts Institute of Technology (MIT). As shown in the previous figure, from 2016 to recent years, IoT grows faster than WSN, leading the research field, thanks to developments and applications based on IoT from large companies worldwide such as Google, Amazon, and Apple. Besides, due to the increase in IoT systems, a large amount of data has been generated from different sensors; however, processing and analyzing said data is a great challenge, with the analysis algorithms being of great importance [27]. Figure 4 shows the number of articles related to IoT and WSN published in both databases.
Due to the Internet Protocol (IP) in WSN networks, both concepts began to coexist in research. Therefore, Figure 3 results from an analysis of the number of articles per year with keywords related to WSN, based on a previous analysis of the keywords related to IoT (articles that have both keywords). Approximately 50% of the investigations have been carried out in the last year (between 2018 and 2019).
Figure 5 shows the number of articles published per year on IoT and WSN. The Y-axis represents the number of articles published per year, the X-axis the timeline, and the blue color the published documents that deal with both keywords (IoT and WSN). It is evidenced that approximately since 2008, both concepts began to coexist in research. Their highest research growth has been since 2016 when the number of investigations that integrate IoT and WSN began to have a growth rate much higher than in previous years.
Finally, IoT is a trending concept that has been integrated with WSN networks for a logistics approach in Industry 4.0.
3. Materials and methods
Next to be described will be the development environment; then the methodologies implemented in this work, the metrics, variables, and the validated multilayer model.
3.1. Development environment
Android Studio
Android Studio was used during the development of this mobile application. It is an Integrated Development Environment (IDE) used mainly in the outcome of applications for Android. This allows applications to be developed using the Kotlin or Java programming language depending on the developer’s preference [28]. The application was developed on version 3.6 of Android Studio.
ScientoPy
This is a tool used for scientometric analysis based on Python. ScientoPy was developed at the Universidad del Cauca. Among its main characteristics are the following: import the data set from the Clarivate Web of Science (WoS) and Scopus bibliographic databases. Then filter publications by type of document, combine the WoS and Scopus data set based on a correlation table of field labels, find and eliminate duplicate documents, extract the H-index for analyzed topics, search for wildcard topics, find trending topics and make different graphs. These will allow different visualizations (timeline, evolution, bar, bar trends and word cloud), find principal authors, institutions or countries based on the authors of the first document or all authors of the document, generate report table and short preprocessing graph [29,30].
3.2. Methodology
For the application developed as the proposed validation alternative in Android Studio, the Scrum methodology was implemented in conjunction with TDD. These achieve agile software development based on good programming practices. Also, the review methodology was carried out by implementing the Scientopy tool.
Methodology for application development – Scrum
Scrum is a framework used to develop software and deliver it at the expected time straightforwardly. This frame of reference uses the concept of “Team.” In this working group, each member plays a specific role [31]. Its components are meetings, these being Backlog planning, Sprint monitoring, and review of the Sprint. Five roles are assumed: Product Owner; Person who thoroughly knows the ideas and requirements of the client. ScrumMaster; checking the correct functioning of the model. Development team; a small group of people who develop tasks. Users; who receive the final product. Stakeholders; people who will benefit from the project and participate in the review meetings. And finally, the Manager decides according to the objectives and requirements. The last of the components is called Scrum elements, such as the Product Backlog or Sprint Backlog [32].
The Scrum framework was applied in the project to design and develop the application. The Scrum Team is made up of different people with a specific role. Every Monday, a meeting was attended to review the Sprint developed during the previous week. At the meeting, each member of the Development Team reported on the execution and completion of their weekly tasks. The other team members provided feedback. The Scrum Master planned the next Sprint and assigned the tasks to each member of the Team. These tasks included Scientometric reviews over concepts related to Industry 4.0, IoT, and WSN.
Methodology for the Development of the Application- Agile TDD Methodology
The test-driven development (TDD), according to Araújo (2012), “… is an iterative and incremental discipline of design and programming. Here each new line of code is written in response to a failed test …” [32]. The steps on this methodology are: write a test; run all the tests and check it fails; add code necessary to pass the test; run all the tests again and verify they pass; at last, rebuild to eliminate unnecessary code and duplications. A typical TDD test is defined for basic functionality to extract each variable’s decimal value from intercepted data frames in hexadecimal format. The test will fail because there is no code written for that function. Later, the programmer writes the code that allows us to analyze the data frame, extract the bytes from the required variable’s field, and transform them to a decimal value to return it. The test runs again and passes correctly. Then, the programmer simplifies and refactors the code.
Different functions of the application are cyclically coded. We generate cases of JSON data parsing unit tests (76 tests) to develop a code that analyzes captured JSON messages (through intents). Moreover, we perform unit tests using TDD (207tests) to develop a code that analyzes the captured hexadecimal messages (throughthe Sniffer and intents) according to the data frames characterized in the previousactivity and save the analyzed data in variables.
Metrics, Variables, and Multilayer Model
This section describes the variables obtained from the sensor’s measures that are inside devices called Tags. It also describes the multilayer model to be validated. i) Metrics refers to tag measurements of the WSN system, such as number of seconds elapsed, light intensity, relative humidity, temperature, pressure, percentage of available battery, number of strokes, transmission power, angle of inclination, number of touches. ii) The variables related to each metric were: timestamp, sensor type, measurement status, value, an indicator of the value within the range, and the value outside the range. iii) Multilayer model was represented for the three different layers. The developed multilayer model is described in Figure 6.
  • Layer one: Intercepting with the Sniffer. The first layer refers to the process in which the communication between the Tag and the Gateway was interfered by a device called Sniffer. This device sent the interfered messages to the Gateway throughout the serial port, which has an encrypted message. This content has to be analyzed by the structure of its frames in order to obtain the data of each variable previously named.
  • Layer two: Capturing the UART Intent. The second layer represents the process in which a message captures an Intent transmitted by another application installed on the Gateway. The message was encrypted differently. This takes into account the structure of its frames. This message was analyzed to obtain the data of each variable previously named.
  • Layer three: Capturing the Intent of the JSON. The last layer refers to the process in which a message with JSON format was captured. This happens through an Intent transmitted by another application installed in the Gateway (in charge of sending the information to the cloud). The captured message was analyzed to obtain the data of each variable previously named.
4. Results
As shown in Figure 7, the developed WSN-IoT system encompasses a set of sensor nodes called Tags. These devices collect the data from their sensors in a defined sampling scheme, then process and store the data until a connection with a Gateway where the message with data is packed, modulated, amplified, and transmitted to a Gateway through a network LR-WPAN. Following the IEEE 802.15.4 standard, data transmission and reception were carried out through a radio channel operated in the 2.4GHz frequency band. This is characterized by having 16 channels ranging from 2.4 to 2.4835 GHz. and a bit rate per channel of 250 kbps. The devices operated in that shared wireless channel used the technique of time-division multiplexing (TDM) in a synchronous way guided by local timers and the payload of the WSN packets.
The application detects the information loss and data transmission errors developed in the system. This application was programmed with the ability to validate the transmission of data. It occurs through each of the layers of the implemented model. Figure 8 shows that the application has three main modules (Sniffer-type parser, UART-type parser, and JSON-type parser). Each has a message encoded as input, as described below:
Module 1 Sniffer type analyzer: This module has an input message with Hexadecimal notation. It comes from the Sniffer through the serial port of the Gateway. Module 2 UART analyzer: This level also has an input message with a Hexadecimal notation from the Server throughout an Intent through a Broadcast receiver. Module 3 JSON type parser: Has an input message with JSON notation coming from the Gateway throughout another Intent through a Broadcast receiver.
The Broadcast receivers are used to listen to the Intents or broadcast attempts. A Broadcast Intent can be a message sent by a specific application to all other applications installed on the device. However, its Intent can only be received by an application that has a broadcast receiver correctly enabled for that Intent.
After receiving the messages (with different encodings), they proceed to decode them. After that, the application obtains the data for each variable. Each data is analyzed and compared with the data of each level. If all data matches perfectly, no message is assigned to the status of the variable. However, if any data is lost or the value is incorrect, an “Error” message is assigned to the status of the incorrect variable.
Subsequently, the data of the variables obtained are stored in the Random Access Memory (RAM). This memory is commonly used to store temporary applications and data of a device while it is being used [33]. Simultaneously, a timer is running continuously in the application. After a specific time (modifiable according to requirements), the data is updated and incorporated in the RAM into a file that contains a comparative data report.
Figure 9 represents the algorithm’s general description through a flow diagram, which contains sub-processes within it. It is described by other flow diagrams (one for each module).
According to the flow diagram, the application process begins with the verification of “ComparisonFiles” folder. If it does not exist, a folder with the same nameand the file “Comparison-yyyy-MM-dd-HH-mm.txt” is created.If the folder exists, the process verified the file existence, and if necessary, createsa new file. Furthermore, usinga “Singleton,”a “HashMap” or map with a single instance is created;the structure is in Figure 10.
Later, the following three threads will start running simultaneously:Sniffer-type parser, UART-type parser, and JSON-type parser (Figures 11, 12, and 13). Each sub-process has an input encoded message analyzed through its respective process to obtain and store output variables. Then every N minutes, the previously named file is updated with the variables obtained. Finally, a file is obtained in which all the variables of each of the three modules are compared.
Table 1 is an example of the application’s analysis in monitoring the variable “Light.”It measures the light intensity sensed by a Tag. This analysis allows for observing thestructure of the resulting comparative file for the validation of the data. The “Entry”column defines the layer where the data was received. Layer one is represented bythe word “Sniffer,” two by the word “UART,” and three by the word “JSON.” “TagID”indicates the ID of the Tag that sent the message. “EpocTime” represents the instant oftime in which the message was received in each layer. This variable is one of the mostimportant. It allows the data to be compared at the three levels simultaneously. “Light”shows the different metrics obtained by the sensors of each Tag and transmittedto each layer of the system. Finally, “Status Light” reports each metric’s status. Thebox remains empty if there were no errors in the data transmission between layers.The opposite case is if the word “ERROR” appears in the state of any variable, thusinforming that there was some data transmission error in a specific layer. In the sameway, the analysis is carried out automatically for the other variables (generally, errorsin data transmission appear when the Tag goes out of the Gateway’s coverage area).
Finally, to corroborate the developed application operation, different tests werecarried out and successfully passed. Initially, the correct execution of each of thecode’s functions developed for modules one, two and three was validated by applyingTDD unit tests in Android Studio.
These tests covered test scenarios like data analysis from one Tag with all active sensors, one Tag with some active sensors, and one hundred Tags with different active sensors, checking each variable to analyze which of those specified in the data frames are equal (Module 1 and 2); analysis of the length of the mainframe and its subframes (Module 1 and 2); and incomplete JSON message analysis (Module 3).
Subsequently, tests were carried out through different case studies in real scenarios for verifying the correct capture of Intents. The management of the connection of the Sniffer to the Gateway through the serial port, the entry of messages through the serial port, the correct storage of information during long periods, the comparative report in an ideal test scenario without errors and guarantee the execution of the application in the face of exceptions.
The last test performed was in a non-ideal test scenario. The Tag had the Light, Humidity, Temperature, Battery, Shock, and Tilt sensors activated; to produce Tag data transmission errors. This device was wholly covered with aluminum foil to make a Faraday cage. This Tag was removed from the Gateway’s coverage area. This device stored all the data sensed in its memory. Then the Tag was returned to the coverage area. The stored data started to be retransmitted to the Gateway, but at this time, the application reported an error. This error was caused by the loss of packets during data retransmission. Finally, the comparison report was correctly stored in the Gateway. This file was imported into Excel to observe the organized data, and the errors reported. Table 2 is the resulting Excel table.
The developed application eliminated the need to perform the task manually. This application allowed for the optimization of the review process’stime to which the previously developed WSN-IoT traceability system was submitted. The developers of the WSN-IoT system made use of the application to quickly detect lost packages in non-ideal conditions.The time invested in this process was reduced. The manual search for errors took approximately three hours. A more efficient application process is evidenced in tests with several Tags. This application allows for the detection of a more significant number of packets lost per test. The registration of the packets allows for the system developers to find data transmission problems to be treated. Finally, the system is modified to satisfy all user requirements in all case studies correctly.
5. Discussions and conclusions
5.1. Discussions
There are currently a series of projects about Logistics developed by the multinational Libelium, such as the “Intelligent Logistics” project. That project offers real-time monitoring of variables such as location, brightness, humidity, the quantity of carbon dioxide, temperature, and vibration for the subsequent sending of the data to the cloud [34]. However, this WSN-IoT system tracking is offered to a higher number of variables, adding tracking to inclination, pressure, and number of strokes.
Also, there is a large number of mobile applications for WSN that are useful for product tracking and monitoring processes. Among them, the following stand out: Deliveries Package Tracker [35], 17TRACK [36], Parcel Tracker [37], among others; which track the location of shipments through a tracking number entered by the user. The designed application allows for adding information validation to this developed WSN-IoT monitoring system.
The Aconno company developed the BLE Sniffer application, which is in charge of performing its system’s validation. This captures the raw data, deserializing them in types or primitive chains, filtering the data, and providing a report on them; a process very similar to that carried out by Module 3 of our application [38].
The development of this application contributed to the systems framed in logistics and traceability, adding functionalities of validation, analysis, and data comparison in each layer of the implemented model. Therefore, the validation process of the previously developed WSN-IoT system was automated.
5.2. Conclusions
The development of the application was necessary to characterize the structure of data frames and obtain the payload to decode and analyze the information captured for each of the monitored variables’ values. The data analyzed in each module was organized in a “HashMap” map with a unique instance; this map allowed for the comparison, analysis, and validation for the three modules’ variables.
In this investigation, the data transmission validation process of the WSN-IoT logistics system was improved throughout the implementation of the developed application, thus eliminating the need to perform the task manually. The developers of the WSN-IoT system use the application to detect lost packages in non-ideal conditions. The packets’ registration allows the system developers to find data transmission problems to be treated; finally, the system is modified to satisfy all user requirements in all study cases correctly.
This research’s main contribution was to communicate with other programmers, the algorithm and logic development of a mobile application installed in an IoT Gateway as an alternative to optimize the data transmission validation process helping to reduce the time verifying errors in the data transmission of the WSN-IoT system.
This investigation opens up new research lines related to: i) Adding functionalities regarding the validation data in the cloud. ii) Designing visualization mechanisms that allow for the automation of optimization processes in IoT devices for WSN networks. iii) Developing a WSN-IoT system for different architectures and technologies.
Abstract
Main Text
1. Introduction
2. Literature review
3. Materials and methods
3.1. Development environment
Android Studio
ScientoPy
3.2. Methodology
Methodology for application development – Scrum
Methodology for the Development of the Application- Agile TDD Methodology
Metrics, Variables, and Multilayer Model
4. Results
5. Discussions and conclusions
5.1. Discussions
5.2. Conclusions