Implementation of A Data-Acquisition System and Its Cloud-Based Registration Using the Unified Architecture of Open Platform Communications †
Departamento de Automatización y Control Industrial, Escuela Politécnica Nacional (EPN), Quito 170525, Ecuador
*
Author to whom correspondence should be addressed.
†
Presented at the XXXI Conference on Electrical and Electronic Engineering, Quito, Ecuador, 29 November–1 December 2023.
Eng. Proc. 2023, 47(1), 20; https://doi.org/10.3390/engproc2023047020
Published: 7 December 2023
(This article belongs to the Proceedings of XXXI Conference on Electrical and Electronic Engineering)
Abstract
:Standardization and collaborative integration are fundamental for the implementation of Industry 4.0. The Open Communication Platform Unified Architecture (OPC UA) standard plays a crucial role in communication by enabling the development of heterogeneous systems and facilitating the seamless exchange of data between devices. To take full advantage of OPC UA’s capabilities, it is necessary to unlock other application services, such as cloud computing. By having more tools at their disposal, industries can increase their efficiency and optimize data-driven decision making. In this study, it was proposed to use OPC UA standard in a Client/Server model to leverage OPC UA paradigms along with Software Development Kits (SDKs). The development was carried out using Python as the programming language, both to host the server on a Raspberry Pi 4B and to set up the client on a Personal Computer (PC). This client will centralize the data for sending to the Clever Cloud logging platforms and for web visualization on Tago.IO. The interoperability problem of communicating between two platforms with different Operating Systems (OS) was addressed by integrating the OPC UA standard. The configured interval of 10 s recorded an average of 11.11 s, with a maximum timeout of 59 s for data-logging temperature, pressure, humidity, and altitude. The client proved to be Hypertext Transfer Protocol Secure (HTTPS) compliant, allowing connection to Web platforms.
1. Introduction
In Industry 4.0, industrial control and monitoring systems must be at the forefront, demanding constant research [1]. Tools such as data mining, the internet of things, automation, additive manufacturing, cloud computing, and renewable energies are used to create value and improve services, work organization, and business models [2]. However, the variety of industrial communication technologies makes it difficult to integrate applications [3]. Currently, there are several industrial communication protocols based on the Industrial Ethernet (EI), such as EtherNet/IP, PROFINET, or EtherCAT, widely used but not compatible with each other [3]. This generates problems for sharing information with information technologies (IT). To address this, the OPC UA standard is adopted, which harmonizes protocols by offering equivalent functions, communication security, and flexible design [4]. From an economic perspective, it would be beneficial to apply OPC UA in open hardware devices like Arduino since, according to [5], they can drive projects due to their low cost, making them ideal for proposal development. This would enable the use of cloud-computing tools, promoting standardized communication in the field and interoperability with IT and Industry 4.0 tools.
2. General Definitions
The OPC Foundation developed two industrial standards. The first one, called OPC Classic, aims for interoperability in automation, but it relies on Windows and DCOM, which limits online communication [6]. To address this, the OPC UA standard was created, which utilizes high-performance protocols for communication [7].
OPC UA Client/Server model: OPC UA uses the Client/Server model. Clients initiate communication and connect to servers [7]. Servers provide data and respond to client requests. This is useful for collecting data in distributed control systems, where a Master Terminal Unit (MTU) acts as a client to obtain information from Remote Terminal Units (RTUs) and can also serve as a server to share data with other OPC UA clients.
OPC UA addresses: OPC UA addresses communication and information modeling. The server consists of address spaces with nodes and attributes [7]. Nodes have attributes that describe the information. The unique identification of nodes allows clients to access attribute values in service requests.
OPC UA security: According to [7], the OPC Foundation establishes different levels of security for communication between the server and client in OPC UA, ranging from no security to high security: None, Basic128Rsa15 (medium-level security), Basic256 (medium-high-level security), and Basic256Sha256 (high security). Additionally, the OPC Foundation offers various methods of authentication, including Anonymous (no user data), User (requires username and password), X509v3 (uses digital certificates), and Certificate (employs security tokens for authentication).
OPC UA data transport: The protocols for clients and servers to share data in OPC UA include TCP, which provides a reliable full-duplex communication channel that is connection oriented, and SOAP/HTTP, which operates with structured SOAP messages transmitted over HTTP, enabling a secure data exchange between devices [7].
3. State of the Art Study
Here are some similar studies to this project. A study conducted by [8] focuses on establishing a sensor network using Arduino devices and MQTT communication to manage transmission between sensors. This is integrated with cross-platform applications through the OPC UA standard, which serves as a solution to centralize communication between devices and the data they generate. Grafana is used for data analysis afterward, with Java programming language highlighted throughout the process.
In the works [9,10], the focus is on the OPC UA standard, although they address different applications and contexts. In the first work, a server is implemented on a Raspberry Pi 2, enabling communication between devices using the Modbus and OPC UA protocols. On the other hand, the second work employs a server on an Arduino Yun for communication between devices using Serial communication and the OPC UA protocol, although bottlenecks were identified on this board. In both cases, commercial OPC UA clients were used for communication with the server.
4. Development of the Proposal
Figure 1 depicts the connection diagram of the utilized devices. The Raspberry Pi 4B board (server) employs I2C communication to interface with the transducer, and utilizes OPC UA to establish a connection with a personal computer (client). This computer is responsible for reading and centralizing the data, subsequently employing cloud-computing tools such as database storage and graphical interface visualization.
4.1. OPC UA Server Configuration
The I2C protocol is used to connect the Raspberry Pi 4B with the BME280 transducer. The transducer’s parameters are configured, and values for temperature, pressure, humidity, and altitude are captured. Subsequently, an OPC UA server is created using the asyncua Server SDK. Address spaces are established for the variables. For security purposes, the Basic256Sha256 security suite is configured, utilizing AES 256-bit encryption and the SHA-256 algorithm. Secure communication is established by incorporating the certificate and key.
4.2. OPC UA Client Configuration
Creating an OPC UA client is essential to accessing data from the server and connecting the OPC UA standard with cloud services. The programming steps are outlined below.
Connecting to the OPC UA Client: OPC UA connectivity is implemented using the asyncua Client SDK. A connection class is created with a constructor that receives the server’s address, security indicator, certificate path, and private key path (if necessary). The constructor initializes the server’s address and creates an instance of the OPC UA client. Another method verifies the connection and returns true.
Connection for logging: PyMySQL SDK is used to connect the application to the Clever Cloud database. In the connection class, the necessary credentials for communication are configured. Then, a cursor is created to execute queries, and a connection verification method is implemented, returning a positive value if the connection is established.
Connection for visualization: A class is included to link the application with the Tago.IO platform through its SDK. Similar to other connections, an initialization method is used for the connection parameter, which is a key specifying access to Tago.IO. Connection verification is done using a method to determine the success of the connection.
Data acquisition from the server: A proposal to implement code for reading and storing OPC UA server addresses is presented. The code consists of two methods: one for initial configuration and another for reading variables. In the first method, dictionaries are used to manage variables, recording them for cloud database and visualization purposes. Attributes are also set to indicate that the attributes have not yet been recorded. The second method reads specific values on the OPC UA server, using arguments for the address and node name, along with optional configurations for recording or visualization. The presence of values in the dictionary is checked before recording, and SQL queries and lists are created for sending to Tago.IO.
Graphical user interface (GUI): A graphical interface designed in QT Designer is utilized to create a GUI that enables the configuration of the OPC UA client with cloud-computing tools. The interface comprises three sections: control buttons, an options bar, and a workspace. The options bar is divided into Configuration (for connection data and address space), Status (displaying nodes and names), Visualization (displaying data), and Help (documentation). Figure 2 displays the configuration interface with fields for input and project execution, along with OPC UA client code parameters.
4.3. Platform Configuration
Database configuration: To store data from an OPC UA client, Clever Cloud is utilized to create an SQL database integrated into the project. Management is conducted through PHPMyAdmin. A table is configured for the variables such as date, temperature, pressure, humidity, and altitude, before establishing the OPC UA client. The date field will be entered each time a value is recorded, and the variables can be nullable since the input of variables from the GUI is singular in nature.
Visualization-platform configuration: The project aims to display data from the OPC UA client in an internet-accessible interface. A HTTPS device was created in Tago.IO, linked with the OPC UA client using a token from the created device, and variables were matched with widgets for visualization. Additionally, this platform provides alert tools based on registered values.
5. Results and Discussion
The tests were conducted in a closed test environment equipped with a temperature and humidity controller, along with an RH35 data logger, to study how the proposal operates under real operating conditions. The testing process began with assessing the connection between platforms and the OPC UA standard. Subsequently, tests were conducted to capture data using cloud-computing tools, involving 8 h trials for intervals of 10, 20, and 30 s. These tests verified data and service availability. Additionally, a comparison was made between the data stored by the RH35 logger and the data recorded in Clever Cloud.
5.1. Testing Connection with OPC UA and Proposed Services
The communication involves an OPC UA server on a Raspberry Pi 4B, and a client on a PC. Communication and connection tests were carried out for recording and visualization purposes. In the first test, the server had no security level. The configuration included URLs and credentials for Clever Cloud and Tago.IO. The connection was tested with a security level, using self-signed certificates from OpenSSL on both the server and the client. The connections were successful, as indicated by the green status bars. Once the respective connections were established, platforms were usable, and nodes could be configured to avoid conflicts.
5.2. Results of OPC UA Implementation and Proposed Services
The tests verified the average recording time for different intervals and the functionality of the platforms. Variables like temperature, pressure, and humidity were monitored to assess the data accuracy. The results were presented in Figure 3, with the red line representing Clever Cloud and the blue line representing the RH35 logger.
Table 1 displays records and averages of temperature, pressure, and humidity, along with the Root Mean Square Error (RMSE) obtained.
First test (7 June 2023, 09:00): A duration of 8 h with 10 s intervals. No errors were detected. The maximum interval between records was 59 s. The average between records was 11.11 s. Second test (8 June 2023, 09:00): A duration of 8 h with 20 s intervals. No errors were recorded. The maximum interval between records was 50 s. The average between records was 21.10 s. Third test (9 June 2023, 09:00): A duration of 8 h with 30 s intervals. There were no errors during the test. The maximum interval between records was 51 s. The average between records was 31.14 s.
The differences between the data can be attributed to the relatively lower precision but cost-effective nature of the Raspberry Pi and the BME280 transducer. The project’s focus lies in monitoring and recording data in the cloud for storage and visualization through cloud computing. RMSE was employed to gauge the discrepancy between estimated (Clever Cloud) and actual (RH35) data [11]. A Python script calculated RMSE as the squared difference between these datasets, with lower values indicating higher precision.
Linear interpolation was used to estimate missing data in the logging device, which had a minimum interval of 30 s. In terms of temperature, it was observed that a greater interval between measurements led to higher precision (lower RMSE). Pressure maintained a consistent range across different intervals. Humidity also improved its precision with longer intervals. Shorter records offer a detailed view of changes, while longer records provide a general and smoothed perspective.
Tago.IO was useful for visualizing measurements and alarms, updating in sync with the database, and rapidly translating information into graphs and alerts. The platform is accessible on devices with an internet connection.
6. Conclusions
A technological solution was implemented using OPC UA to monitor variables like temperature, pressure, and humidity during 8 h tests. Despite some delays in data visualization, the Python-based solution offers flexibility for monitoring systems in industrial environments. The implementation demonstrated communication between devices with different operating systems (Raspberry Pi OS and Windows 10) and the integration of cloud-computing platforms such as Clever Cloud and Tago.IO for data recording and visualization. Although limited by using free plans, it did not affect data availability.
Prototype tests confirmed the stability and reliability of the monitoring system in a real environment for four variables. There were wait times due to network conditions and platform services, which could be improved with paid services or local servers.
OPC UA standard is compatible with HTTPS, making its implementation on Industry 4.0 platforms easier. The configurable interface connects with OPC UA clients, recording data in the cloud and visualizing it on the web.
The current project is primarily focused on monitoring, but in the future, it could incorporate the Network Time Protocol for precise synchronization in control applications alongside OPC UA. Additionally, a potential option for future updates could involve having a local visualization interface that includes iconography to enhance data comprehension within the OPC UA client application.
Author Contributions
Conceptualization, A.M. and D.V.; methodology, A.M.; software, A.M.; validation, A.M., D.V. and A.R.; formal analysis, A.M.; investigation, A.M.; resources, A.M.; data curation, A.M.; original draft writing, A.M.; writing, revision, and editing, A.M., D.V. and A.R.; visualization, A.M. and A.R.; supervision, D.V. and A.R.; project administration, A.M. All authors have read and agreed to the published version of the manuscript.
Funding
This research received no external funding.
Institutional Review Board Statement
Not applicable.
Informed Consent Statement
Not applicable.
Data Availability Statement
The following link is shared where you can find the Python script to obtain the displayed graphs, as well as the values from the table. Additionally, the link contains the data frames used in the analysis. (https://mega.nz/folder/jNpAHTyT#JySXOJ8C8rR3SX5O3ttUNQ (accessed on 25 October 2023)).
Conflicts of Interest
The authors declare no conflict of interest.
References
- Sodhi, H. When industry 4.0 meets lean six sigma: A review. Ind. Eng. J. 2020, 13, 1–12. [Google Scholar] [CrossRef]
- Gallo, T.; Cagnetti, C.; Silvestri, C.; Ruggieri, A. Industry 4.0 tools in lean production: A systematic literature review. Procedia Comput. Sci. 2021, 180, 394–403. [Google Scholar] [CrossRef]
- Drahos, P.; Kucera, E.; Haffner, O.; Klimo, I. Trends in industrial communication and OPC UA. In 2018 Cybernetics & Informatics (K&I); IEEE: Piscataway, NJ, USA, 2018; pp. 1–5. [Google Scholar] [CrossRef]
- Schwarz, M.H.; Borcsok, J. A survey on OPC and OPC-UA: About the standard, developments and investigations. In Proceedings of the 2013 XXIV International Conference on Information, Communication and Automation Technologies (ICAT), Sarajevo, Bosnia and Herzegovina, 30 October–1 November 2013; IEEE: Piscataway, NJ, USA; pp. 1–6. [Google Scholar] [CrossRef]
- Kim, S.-M.; Choi, Y.; Suh, J. Applications of the Open-Source Hardware Arduino Platform in the Mining Industry: A Review. Appl. Sci. 2020, 10, 5018. [Google Scholar] [CrossRef]
- McIlvride, B.; Thomas, A.; Real, C. OPC Tunnelling–Know Your Options; Cogent Real-Time Systems Inc.: Mississauga, ON, Canada, 2008. [Google Scholar]
- Mahnke, W.; Leitner, S.-H.; Damm, M. OPC Unified Architecture; Springer Science & Business Media: Berlin, Germany, 2009. [Google Scholar]
- Vimos, V.; Sacoto Cabrera, E.J. Results of the implementation of a sensor network based on Arduino devices and multiplatform applications using the standard OPC UA. IEEE Lat. Am. Trans. 2018, 16, 2496–2502. [Google Scholar] [CrossRef]
- Muller, M.; Wings, E.; Bergmann, L. Developing open source cyber-physical systems for service-oriented architectures using OPC UA. In Proceedings of the 2017 IEEE 15th International Conference on Industrial Informatics (INDIN), Emden, Germany, 24–26 July 2017; IEEE: Piscataway, NJ, USA; pp. 83–88. [Google Scholar] [CrossRef]
- Pena, R.R.; Fernandez, R.D.; Lorenc, M.; Cadiboni, A. Gateway OPC UA/Modbus applied to an energy recovery system identification. In Proceedings of the 2019 XVIII Workshop on Information Processing and Control (RPIC), Bahia Blanca, Argentina, 18–20 September 2019; IEEE: Piscataway, NJ, USA; pp. 235–240. [Google Scholar] [CrossRef]
- Kambezidis, H.D. The Solar Resource. In Comprehensive Renewable Energy; Elsevier: Amsterdam, The Netherlands, 2012; pp. 27–84. [Google Scholar] [CrossRef]
Figure 1.
Proposed system architecture.
Figure 2.
GUI for OPC UA Client.
Figure 3.
Implementation tests: (a) Timeline of the test with a 10 s interval; (b) timeline of the test with a 20 s interval; (c) timeline of the test with a 30 s interval.
Figure 3.
Implementation tests: (a) Timeline of the test with a 10 s interval; (b) timeline of the test with a 20 s interval; (c) timeline of the test with a 30 s interval.
Table 1.
Presentation of the results achieved during the tests.
| Interval | Variable | Devices | Records | Mean | RMSE |
|---|---|---|---|---|---|
| 10 s | Temperature (°C) | RHT35 | 1128 | 23.85 | 1.44 |
| Cloud | 2951 | 23.26 | |||
| Pressure (hPa) | RHT35 | 1128 | 734.15 | 1.36 | |
| Cloud | 2951 | 735.41 | |||
| Humidity (%) | RHT35 | 1128 | 47.86 | 4.52 | |
| Cloud | 2951 | 48.25 | |||
| 20 s | Temperature (°C) | RHT35 | 1091 | 23.67 | 1.02 |
| Cloud | 1543 | 23.13 | |||
| Pressure (hPa) | RHT35 | 1091 | 734.77 | 1.33 | |
| Cloud | 1543 | 736.04 | |||
| Humidity (%) | RHT35 | 1091 | 47.49 | 4.21 | |
| Cloud | 1543 | 46.64 | |||
| 30 s | Temperature (°C) | RHT35 | 1085 | 24.29 | 0.94 |
| Cloud | 1043 | 23.68 | |||
| Pressure (hPa) | RHT35 | 1085 | 734.91 | 1.21 | |
| Cloud | 1043 | 736.06 | |||
| Humidity (%) | RHT35 | 1085 | 46.95 | 4.02 | |
| Cloud | 1043 | 46.16 |
Disclaimer/Publisher’s Note: The statements, opinions and data contained in all publications are solely those of the individual author(s) and contributor(s) and not of MDPI and/or the editor(s). MDPI and/or the editor(s) disclaim responsibility for any injury to people or property resulting from any ideas, methods, instructions or products referred to in the content. |
© 2023 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (https://creativecommons.org/licenses/by/4.0/).
Share and Cite
MDPI and ACS Style
Molina, A.; Vargas, D.; Rodas, A. Implementation of A Data-Acquisition System and Its Cloud-Based Registration Using the Unified Architecture of Open Platform Communications. Eng. Proc. 2023, 47, 20. https://doi.org/10.3390/engproc2023047020
AMA Style
Molina A, Vargas D, Rodas A. Implementation of A Data-Acquisition System and Its Cloud-Based Registration Using the Unified Architecture of Open Platform Communications. Engineering Proceedings. 2023; 47(1):20. https://doi.org/10.3390/engproc2023047020
Chicago/Turabian StyleMolina, Anthony, Diego Vargas, and Ana Rodas. 2023. "Implementation of A Data-Acquisition System and Its Cloud-Based Registration Using the Unified Architecture of Open Platform Communications" Engineering Proceedings 47, no. 1: 20. https://doi.org/10.3390/engproc2023047020
