Supervisory Monitoring and Control Solution on Android Mobile Devices for the Water Industry 4.0

Abstract

The capacity for using mobile devices for monitoring and controlling local processes has seen rapid growth in industry for maintenance operations before and after deployment. This is especially important in the case of geographically widely-dispersed locations, such as in the case of the water sector, where processes, technologies, and local automation solutions are widely spread. Usually, the available mobile solutions are dependent on Supervisory Control and Data Acquisition (SCADA) software installed in the control rooms of water and wastewater facilities, usually without configuration possibilities. Considering the various SCADA control rooms, each focusing on a specific system, and hundreds of smaller locations accessible only with PLC and eventually a small touch screen, the dependence on local SCADA software is proving increasingly impractical. This paper presents the implementation of an easy-to-use SCADA system for the Android operating system, conceived following Industry 4.0 concepts. An OPC UA client-based architecture is proposed to cope with current interoperability standards, mobility and security across industrial processes in various domains. The design relies on a foreground service for uninterrupted communication between the application and the OPC UA client. The system is envisaged to provide notifications to alert the user when alarms are triggered, including both an independent application level alarming module and a new Alarms and Conditions based protocol level module, increasing visibility and response time for technical issues or faults, and being adaptable to both legacy and modern OPC UA specifications. The solution was tested first in the laboratory to validate the communication system with as many OPC UA structures as possible, and then in real scenarios with drinking water and wastewater systems interfacing PLC, HMI and SCADA level OPC UA servers. The tests in the real scenarios included a second-level test for water operators and engineers which accessed and monitored various processes with the developed solution, and all results proved to be satisfactory.

1. Introduction

Automation has evolved rapidly in recent years due to concepts such as the Industrial Internet of Things and Industry 4.0 [1,2]. Supervisory Control and Data Acquisition systems (SCADA) are widely used in industries, including energy, water and wastewater treatment, manufacturing and more. They are designed to collect data from equipment and sensors in real time or close to real time. SCADA systems provide an overview of processes which can be monitored and controlled. Furthermore, SCADA systems can generate alarms and generate graphs for events when specific conditions are met. One of the key components of a SCADA system is a Human–Machine Interface (HMI), by which operators interact with the system. As presented in [3,4,5,6,7], because of fast advancements in technology, more and more SCADA systems are using mobile devices as an additional user interface infrastructure. Some of the key advantages of using mobile devices in industry are as follows: remote monitoring (especially useful for rural areas or remote sites) [8,9]; real-time data access, where taking fast decisions can be crucial; faster system tests and deployment; precise maintenance; and cost-saving by reducing the costs of travel and accessibility. As a result, specialists in the field can allocate their resources and time with greater efficiency. In addition, safety can be greatly improved by using mobile devices in industry. Real-time alerts can help improve response times to emergencies and accidents. Refs. [10,11] highlight the importance of real-time monitoring in case of system failures which can affect the safety and stability of the power industry. In the water industry, rapid detection of water quality issues and continuous monitoring can enable fast emergency response to any deviations from set standards, increasing the potential for increasing public safety [12].

A great use of SCADA systems is presented in [13], where a SCADA system is proposed to simplify the monitoring process for data while sending alarm notifications to the user when pH values are not in the desired range. In [14,15] cost-effective SCADA systems were developed for solar water pump and solar photovoltaic systems for monitoring and remote control. In [16], a SCADA system was used to send alerts in case of any abnormal conditions or energy theft, by sending a mobile message to the maintenance engineer. Furthermore, ref. [17] presents how industrial automation can minimize the risk of accidents by monitoring and controlling the system.

In industry, SCADA systems are well paired with the Open Platform Communication Unified Architecture (OPC UA) protocol [18,19,20], a key enabling protocol for Industry 4.0. OPC UA follows the old Windows-dependent classic OPC. SCADA software packages with OPC UA capabilities include Wincc [21] 7/OA/TIA/Unified, Ignition, IGSS, etc. Notable OPC UA manufacturers are PTC, Softing and Matrikon. Studies such as [22] show the processes involved in integrating an OPC UA client in order for them to gain authorized access for monitoring and receiving alarm information. Furthermore, other examples of the potential of Android mobile applications for building monitoring solutions for IoT can be seen in [23,24].

However, in the majority of situations the mobile devices are used as extensions of the main SCADA software, so that the mobile application is dependent on a main application which resides and functions on servers in a SCADA control room. In the water sector, SCADA control rooms are associated with specific drinking water or wastewater treatment plants, or other objectives, and the integrated information refers only to the specified process. The majority of mobile SCADA extensions only allow specific interfaces (dependent on the main SCADA application in a control room), without the capability to configure or change diagrams, graphical objects, connections, alarms, etc. There are a few environments which allow specific developments on mobile devices, but these are also dependent on central gateways or are quite expensive. Therefore, the purpose of the current work is to present an independent SCADA solution for mobile devices which is flexible, easily adaptable, and interfaces with local systems through OPC UA. This structure offers the possibility of independent alarm management, and also the possibility of using the new Alarms and Conditions (A&C) OPC UA specification.

This solution is designed for multiple deployments on different devices, with the initial solution being deployed from a central source. Thus, each device can be configured individually so that a water company with geographically widely-dispersed objectives and personnel is able to cover all its infrastructure. Furthermore, due to its flexibility and adaptability, the solution can be applied to numerous industries, including manufacturing, chemical, and energy, where automation proves to have a great impact in increasing quality, efficiency and reducing costs [25,26]. A diverse set of graphic assets have been included in the application to represent a wide range of industrial processes.

A previously implemented solution and a detailed description of the architecture and the relationship between field devices and the application was presented in [27], as a first step towards a stable and complex system. Thus, in this version, several existing functionalities from the previous version were improved, such as connecting to an OPC UA server, browsing, and subscribing to enhance the stability, security and usability of the application. Furthermore, more features were added, such as designing and deploying diagrams for real-time monitoring and controlling of data; and configuring alarms to enhance the utility and complexity of the system.

The paper is structured as follows: Section 2 presents the architecture, Section 3 describes the implementation, followed by results and conclusion in the last sections.

2. Architecture

The design of the Android application client is based on the Java programming language.

When the application launches, a new Linux process starts with a single thread of execution called main thread. In this thread, all interactions with UI components are handled. When performing heavy tasks, such as network operations, on the main thread, the entire user interface becomes blocked. This can even cause the application to display an “application not responding” dialog message. In the first version of the application [27] the connection to the OPC UA server was via the main thread. To the user the application seemed to be frozen while the connection was being established. Applications with newer SDK versions do not allow networking on the main thread, showing a ‘NetworkOnMainThreadException’ message. To avoid this issue and improve performance in this version of the application several background threads were implemented to handle network operations such as connecting to the OPC UA Server, subscribing to NodeIds or disconnecting the OPC UA Client (Figure 1).

Figure 2 depicts the implementation architecture of the application. The application is split into two parts defined by two android Activities: Connect Activity and After Connect Activity. Connecting to an OPC UA server is one of the key aspects of OPC UA client-based architecture [27]. After the connection is establised, other key functions can be accessed, such as subscribing to data changes and events from an OPC UA server for real-time monitoring; reading and writing data from OPC UA servers; browsing and discovering available OPC UA server endpoints; and generating alarms. For these purposes, in the Connect Activity, the user can create a new session by connecting to an OPC UA server, discover endpoints of an OPC UA server by providing the server URI (Uniform Resource Identifier) address or reconnect to an already existing session. The URI is a string of characters used to uniquely identify the location or address of an OPC UA server on a network. It typically includes information such as the protocol used, the IP address and the port number. All operations are conducted using asynchronous tasks that are separated from the main UI thread. The Discover Endpoints feature returns a list of available endpoints from the server to the user. The list contains a number of EndpointDescription objects that provide key information for the client to connect to the server, such as Endpoint URI, Security Mode, Security Policy and Security Certificate. The Endpoint URI represents a specific communication endpoint received from the OPC UA server. It includes the security mode, security policy and the path to the endpoint. Each server can have multiple endpoints, each corresponding to different sets of communication parameters. When the user selects one of the EndpointDescriptions from the list, a new client is created based on the information from that specific endpoint. If the connection is successful, the EndpointDescription object together with the session name set by the user are saved in memory using SharedPreferences. Thus, when the user tries to reconnect to the same session, the EndpointDescription is retrieved from SharedPreferences by its session name. A new UA Client is created and the EndpointDescription with all the data is attached to it. On reconnecting to an existing session, all diagrams and objects are rebuilt in the layout and the subscriptions are recreated for that client.

In order to have reliable and uninterrupted communication between an OPC UA client and server, several aspects were improved. First, a reconnection strategy was implemented. The method setStatusCheckInterval is used to check the server status at a given interval. A listener is used to check when the status of the server changes. If communication issues are detected, the client will try to automatically reconnect to the server. Next, the error handling was greatly improved to avoid application crashes and any lingering time-outs from the client. Some OPC UA servers have a limited number of concurrent connections. This means that if the client is not disconnected properly, a reconnection might not be possible until the other connected client times out. Furthermore, the disconnect process was optimized to handle both manual client disconnection by the user from the UI, and forced client disconnection when the application is closed.

If the connection is successful the second activity will start. This activity serves as the central hub for the application’s functionalities. It contains the menu and a container which are replaced with different Fragments depending on which menu item is selected. For the navigation between Fragments, a Navigation component is used. This component was introduced a few years ago in Android Studio and it provides an easy and clean solution for navigating across different elements within the application and ensures a consistent user experience. On disconnection, the application goes back to the Connect Activity where the user can connect or create another session.

The structure of the menu is composed of Server Status, Browse, Subscribed Objects, Design and Deploy and Disconnect Fragments. The Server Status Fragment shows details about the current connected session, including session name, endpoint URI and the selected security mode and policy. In the Browse Fragment, the user can navigate the address space of the connected OPC UA server and its folders, views, and nodes. The browsing is conducted using an asynchronous task which starts from the root folder and proceeds to add each selection to a Stack to facilitate browsing forwards and backwards with ease. The user can long-press on a Node while browsing to read its attributes based on its Node Class. The Subscribed Objects Fragment displays all the subscribed nodes which have a digital or analog object attached to them which were created in the Design and Deploy Fragment. It displays an object’s name, type, and various attributes depending on its type.

The Design and Deploy Fragment represents the core functionality of the application. A Switch widget is used to change the state from Design to Deploy. In the Design state, the user can add, configure, move, delete, and edit digital or analog objects and alarms. To create a new object, three dialogs are used: (1) creating a new object where title, type (analog/digital), and images are selected; (2) selecting a NodeId for the object by browsing the address space of the connected server; and (3) adding alarms by selecting a NodeId, unique title, message and the condition that needs to be met in order for the alarm to be triggered. Once the fields are filled out correctly and completely, based on the type selected by the user, a new digital or analog object is created. Thus, two custom object types with different characteristics are implemented for digital and analog objects and one for alarms (Figure 3).

Switching to the Deploy state, a Foreground Service is started and all NodeIds from all objects and alarms are subscribed to using an asynchronous task. One challenge in monitoring data from the server was obtaining value changes and alarm notifications when the application was minimized. In this regard, it was essential to implement a Foreground Service so that the data changes within the server are noticeable to the user, even if they are not directly interacting with the application.

For saving data components such as sessions and objects, SharedPreferences API was used. SharedPreferences objects are XML files containing key-value pairs of simple data. Uniquely identifiable names were generated for each object saved in SharedPreferences to perform read and write operations. For more complex data such as custom objects implemented (e.g., NodeDigitalObject, NodeAnalogObject and Alarm), a Gson library was used to convert data to JSON String format before saving it to SharedPreferences. Additionally, when the data are retrieved, the JSON String is read and converted back to the initial object.

3. Implementation of Design and Deploy

This chapter focuses on presenting the implementation of the main feature of the application. The initial implementation of the Design and Deploy Fragment consisted of two separate Fragments: one for the Design state and one for the Deploy state. The switch between the two was controlled by two buttons, one on each Fragment to commute back and forth. Given that each Fragment has its own lifecycle and data, the objects created in the Design Fragment had to be copied in the Deploy Fragment, causing performance and data reliability issues. The Design and Deploy Fragments were combined into one, thus sharing the lifecycle and data to maximize efficiency.

3.1. Implementation of Foreground Service

As mentioned in the last chapter, in order to obtain real-time data from the OPC UA Server, a Foreground Service was implemented. It is used to process data immediately as it becomes available in order to maintain relevance and ensure that the information is as current as possible, even if the application is minimised. The main role of a Service is to execute tasks in the background. Compared to a Thread, a Service can run in the background, even if the application is not being used by the user. Furthermore, a Foreground Service, compared to a Background Service, can perform tasks which are visible to the user. Thus, for this application, a Foreground Service was the suitable option because it can send real-time notifications to the user if alarms are triggered.

To create the service, a new class called ForegroundService which extends the android.app.Service class was created. Correspondingly, a <service> declaration was added to the AdroidManifest.xml file for the new class.

The lifecycle of the Foreground Service in the application is tied to the Switch widget from the Design and Deploy Fragment (Figure 4).

The switch is used to toggle between the Design and Deploy states. When the switch is set to Deploy, if the service is not started, first, the ForegroundService starts and then the service Thread. Next, all the objects created in the Design mode are sent to the service and a subscription to the OPC UA Client is created. If the switch is then set to Design and the service is on, the service and thread are stopped and the OPC UA Client subscription is removed.

When it is created, the Design and Deploy Fragment always starts in Design mode after establishing a connection to an OPC UA server. When switching from Design to Deploy, the startForegroundService() method is called. This method is used to start the service using an Intent. An Intent represents an operation that is performed. In this case, the intent is used to launch and communicate with the service. The startService method will schedule for the service to start (Figure 5).

Similarly, as seen in Figure 6, the stopService method is called to stop the service using an Intent when the mode is switched back to Design.

After the service has started, a NotificationChannel is created. It sends a notification in the notification drawer, signaling that the service started. As the service is supposed to handle blocking network operations, such as subscribing to NodeIds from the OPC UA Client, a Thread is used inside the service. For this, a new HandlerThread is instantiated. The HandlerThread is a thread that has a loop in which messages can be processed until it is stopped. Next, a Handler is created using the HandlerThread. By calling post (subscribe) on the Handler, the subscribe Runnable object is processed and added to the message queue (Figure 7). The role of the subscribe object is to execute the method createSub that is described below.

Firstly, the createSub() method creates and adds a subscription to the OPC UA Client. Then, for each NodeId of digital objects, analog objects and alarms received from the Design mode, a new MonitoredDataItem is created and added to the subscription. If two or more objects have the same NodeId, only one MonitoredDataItem is created and added to the subscription. Then a DataChangeListener is attached to each MonitoredDataItem. By having this listener on a Thread in the Foreground Service new values can be received from the OPC UA server in real time, even when the application is minimized. When a new value for one of the MonitoredDataItems is received from the server the DataChangeListener is triggered and sends the MonitoredDataItem and the new value to a method which finds all digital and analog objects and alarms linked to the MonitoredDataItem’s NodeId (Figure 8).

If the MonitoredDataItem’s NodeId matches the NodeId of a NodeDigitalObject the text of the corresponding TextView is updated in the UI with the new value. Next, if the new value is equal to the value set for the ON state, the object’s state is changed to ON and the ON image set for the object will replace the ImageView in the layout for that object. Otherwise, the object state is set to OFF and the OFF image is shown in the UI. If the object is already in the OFF state the image will not change to avoid unnecessary work and possible crashes due to numerous calls in a matter of seconds. The process is similar if the MonitoredDataItem’s NodeId matches the NodeId of a NodeAnalogObject but without checking for the ON or OFF state. The Symbol image is shown except when the object is in the alarm state. Lastly, if the MonitoredDataItem’s NodeId matches the NodeId of an alarm the digital or analog object that contains that alarm will change its ImageView to the selected Alarm image if the new value fulfils the condition associated with that alarm.

3.2. Alarms and Conditions

The NodeDigitalObject and NodeAnalogObject types have an alarmList field of type ArrayList<Alarm>. Thus, multiple alarms can be set for one analog or digital object. The fields of an Alarm object are presented in Figure 3. The alarms can have the same NodeId as the object they are added to, or a different one. The alarmMode field represents the type of condition that needs to be met in order for the alarm to be triggered. There are two types of modes: those which require one setpoint (value is equal, not equal, above or below the setpoint and the ON Value); and those which require two setpoints (value between or outside the setpoints). Additionally, an alarm can be in the Bit State mode, in which a bit from zero to seven can be selected. The process of checking for alarms is illustrated in Figure 8.

To find objects containing a triggered alarm, first, in the Foreground Service, when a new value for a MonitoredDataItem is received, a Multimap<String, Alarm> containing all alarms is checked. A Multimap is a collection type that can store more than one value against a key. In this case, the key of the multimap represents the alarm’s NodeId as a String, and the value is the Alarm object. A multimap was used because multiple alarms can have the same NodeId and it is more convenient to use compared to Map<String,List<String>>. The reason it was so important to add Alarms by NodeId in a Multimap was because checking for Alarm objects that have the same NodeId as the MonitoredDataItem using Multimap.containsKey() method is faster than traversing multiple lists of Alarms from analog and digital objects each time a new value is received.

Next, if the Multimap contains a key equal to MonitoredDataItem’s NodeId, the Multimap.get() method is used to obtain a collection of all Alarm objects with that NodeId. To check if an Alarm object meets the conditions for the alarm to be triggered, a new method called checkForAlarm() was implemented. In this method, alarm.getAlarmMode() is used to obtain the mode. If the mode is “equal”, “not equal”, “above setpoint” or “below setpoint”, the new value received from the MonitoredDataItem is compared against the value of alarm.getSetpoint() previously set by the user when creating the alarm. If the comparison of the two values (==, !=, <, >) returns true, the method checkForAlarm() will return true. If the mode is “between setpoints” or “outside setpoints”, the new value is compared against the values of alarm.getLowLimit() and alarm.getHighLimit(). If the mode is “Bit State”, to check if the bit is set to one, ((newValue and (1 L << bit_pos)) != 0) is used, where “newValue” is the value received from the MonitoredDataItem and “bit_pos” is the bit position selected by the user when creating the alarm (0–7).

If the method returns true, the analog or digital object that contains that alarm is found. To find the object that contains an Alarm, when the Alarm object was created and added to the digital or analog object, the Alarm Id field was set to be equal to the object’s Id. Next, the digital or analog object’s state is changed to ALARM, the image in the layout is changed to the set ALARM image, alarm.setTriggered is set to true, the alarm.setTime is set to the current time and a new notification is sent to the user. If the method returns false, alarm.setTriggered is set to false and the object’s image and state is changed depending on the new value received.

3.3. Control and Writing Values

In order to remotely control and change the values from the server, a new asynchronous task was implemented. First, for each ImageView in the layout, the registerForContextMenu method is called to make each view display a context menu when the user performs a long-press tap on that view. If Design mode is set, the edit menu is displayed where the user can choose to edit the selected object. If Deploy mode is set, the control menu is displayed as seen in Figure 9.

There are three different control cases:

• The object is digital and its ON state is configured to be a numerical value. To write the ON value for this type of object, first, digitalObject.isValueOn() returns true if the object has a numerical ON value configured. Then, digitalObject.getOnValue() is used to obtain the value of the ON state set for the object. To avoid a possible Bad_TypeMismatch OPC UA status code, the data type of the OPC UA Node linked to the object is checked. For this, the data type of the Node is read using client.readAttribute (nodeId, Attributes.DataType). Next, the ON value is converted to the according data type. To write the new value, client.writeAttribute (nodeId, Attributes.Value, value) is used to change the value of the Node in the server to the ON value with the matching data type. Thus, the object is now in the ON state.
• The object is digital and its ON state is configured to be a bit (0–7). In this case, writing the ON value will set the corresponding bit to one. To check if the digital object has an ON-bit set, digitalObject.isBitwiseON() should return true. Next, digitalObject.getOnBit() is used to obtain the bit position set by the user. In order to check if the corresponding bit is already set to one, the current value of the node is read using the client.readAttribute method. The bit is checked using bitwise operations. If the bit is zero, the client.writeAttribute method will write the new value number with the bit set to one. Similarly, the bit value can be changed from one to zero.
• The object is analog. Here, a dialog opens and the user is prompted to set a new value in an EditText field. Similarly to the other two cases, the data type of the node linked to the object is checked and the value is written using client.writeAttribute for that NodeId.

3.4. Implementation of Progress Bar

Because the number of NodeIds can be significant when creating MonitoredDataItems for monitoring values, a progress bar was implemented to illustrate the progress visibility of the subscribed items. When the mode is switched to Deploy and the service starts, the sum of the number of digital, analog and alarm objects is used to determine the progress bar’s length. The upper range of the progress is set using the setMax() method. Then, the visibility of the progress bar is set to be visible to the user. Changing the visibility in the UI is possible because the process is conducted in the Design and Deploy Fragment before all objects are sent to the service. In the service, for each NodeId subscribed, the progress bar’s progress is incremented. When all NodeIds for all objects are subscribed to, a Broadcast is sent to the Design and Deploy Fragment from the service. A Broadcast is a way to send messages when an event occurs. It uses an Intent object with a string which is used to identify the event which occurred, in this case “completed” (Figure 10).

To receive the Broadcast sent from the service when the subscribe process was completed, a BroadcastReceiver was implemented in the Design and Deploy Fragment using the “completed” string as a filter. Only messages containing this string will be received. On receiving the broadcast, the visibility of the progress bar is set to GONE so it is no longer visible to the user (Figure 11). It was necessary to implement a Broadcast because the visibility of the progress bar can only be changed in the Design and Deploy Fragment so it can run on the UI thread.

3.5. Saving Objects to SharedPreferences

In order to maintain the placement of objects in the layout, the objects and their positions are saved in SharedPreferences. When the object is moved, a new position is recorded and saved in SharedPreferences only when the Fragment is paused to avoid unnecessary write operations of data in the memory.

Figure 12 shows the method used to save a digital object to the internal storage. The getSharedPreferences method is used to obtain the preferences file by a name. If it does not exist, it will be created with that name. In order to distinguish digital and analog objects, two string tags were used. To make sure that the objects belong to the current session, the currentSession name string from the Connection Fragment is appended to the string that represents the type of object. This way, several files are created for the session: one for digital objects, one for analog objects and one for objects’ positions in the layout.

Next, a new Gson object and objectType are instantiated. The objectTtype in this case is NodeDigitalObject. If the digital object is not null, toJSON() method is used to serialize the NodeDigitalObject. As the object is not of a generic type, the object type has to be specified as a second parameter. Lastly, to save the serialized object to SharedPreferences, a key-value pair is put into the file asynchronously using apply(). The key is the NodeDigitalObject’s unique id and the value is the serialized object. If the key already exists in SharedPreferences, the old value is replaced with the new value.

Figure 13 shows the loadDigitalObject() method that is used to retrieve a digital object from SharedPreferences using its unique id. Similar to the saving process, the file containing the digital objects is used in order to retrieve the object. The getString(id, null) method retrieves the object from the file with that id. The second parameter represents the default value that should be returned if the object does not exist. In this case, the method will return null. Similar to the toJSON() method explained above, the fromJSON() method deserializes the specified JSON into an object of the type NodeDigitalObject.

Similarly, to save and retrieve analog objects from SharedPreferences, an object of the type NodeAnalogObjects is returned from the file containing only analog objects for the current session if it matches the given unique id. To save an object’s position, the type Map<String, Pair<Float, Float>> is used. The key represents an object’s unique id and the Pair represents the x and y positions of the ImageView in the layout. The objects and their positions are loaded in the application when the layout view of the Fragment is created.

3.6. Closing the Application or Disconnecting

When the application is closed while the client is connected, After Connect Activity’s onDestroy lifecycle method is called. There, the Foreground Service is stopped, the Subscription is removed from the client and the client is disconnected using client.disconnect() in an asynchronous task. This ensures that the connection is stopped correctly regardless of the Fragment accessed by the user when the application was closed. Similarly, on pressing the Disconnect button in the menu bar, the connection and service are stopped, and the user is sent back to the Connect Activity.

4. Results and Tests

4.1. Overview

The solution was tested both in laboratory scenarios and real scenarios. In the laboratory setting, we assessed the connection and stability of various OPC UA servers by accessing servers from PLC, HMI and SCADA levels, as well as other custom OPC UA servers. In the real scenarios, we established connections to approximately 45 real OPC UA servers. This involved creating systems for both small water and wastewater systems, such as pumping stations and sources, and larger systems, such as treatment facilities. For each system that we tested, we implemented diagrams containing analog, digital and alarm objects, tailored based on the nodes and configuration of each server. Initial real scenario tests were first conducted in collaboration with water engineers, followed by deploying the application to multiple devices sent to production operators for testing.

The application was tested on two mobile devices: a Samsung Galaxy Tab S7 FE (Samsung, Suwon-si, Republic of Korea) with a 12.4″ display and a Samsung Galaxy Tab S6 Lite with a 10.4″ display. Furthermore, an OPC UA server from a partnered local water treatment facility was used for testing. A new session was created with an appropriate name.

After the connection to the OPC UA server was established, a new system was created in the Design and Deploy Fragment by adding several relevant objects for a pump in the Design mode which were then monitored in the Deploy mode (Figure 14).

4.2. Adding a New Object to the System

The process of adding a new object to the layout consists of three dialogs. The first dialog which opens upon pressing the + button is the Configure Object dialog (Figure 14). Here, the data that built the object were configured. The main attribute of an object is the type. Based on the selected type, a NodeAnalogObject or a NodeDigitalObject is created. For the analog object, images for Symbol and Alarm state need to be set, and for the digital object images for ON state, OFF state and Alarm need to be set. For this test, an analog object named “P2_Putere”, which represents the power meter for a pump in the server, was created with the Symbol and Alarm images as shown in Figure 15.

The second dialog was used to link the corresponding NodeId from the AddressSpace of the connected server to the object. The selection of the node was achieved by using a browsing dialog. The node was selected by tapping and holding the node (Figure 16).

Lastly, an Alarm object was added whaich contains the same NodeId as the analog object, a unique name, a message, a mode and a setpoint (Figure 17). The Mode can be set to one of the following: value is equal, not equal, above setpoint, below setpoint, between setpoints, outside setpoints, ON value or Bit state. Depending on the mode, one or two Setpoints are required. Here, the mode is set to “above setpoint” and if the object’s value received from the server is above the setpoint value three, an alarm will be triggered.

By pressing the Finish button on the last dialog, the NodeAnalogObject that is created, as well as the Alarm object, are sent to the Design and Deploy Fragment. Upon receiving the object in the Design and Deploy Fragment, a new ImageView is created to illustrate the object in the UI and two TextViews are added: one for the title and one for the value. The title is placed above the image and the value below. The image can be moved or edited.

4.3. Deploying and Alarms

When switching to Deploy mode, a request is sent for the Foreground Service to start. An icon is displayed in the device’s status bar and a Notification in the notification drawer as shown in Figure 18. Then the monitoring starts.

When the value of the “P2_Putere” analog object is over three a red filter is added over the alarm image to visually indicate the alarm state, as shown in Figure 19.

Additionally, a notification containing the alarm title, object name and value is shown in the notification drawer to inform the user in real time that an alarm was triggered (Figure 20).

All alarms triggered while Deploy mode was on were gathered in a list. If the user taps on the Alarm List button, a DialogFragment containing a scrollable TableLayout is created. For each alarm, a new row is added containing the alarm title, NodeId, message, value, the time when the alarm was triggered and a red alarm image for acknowledgement, as shown in Figure 21. The user can acknowledge an alarm by tapping on it and confirming the action. This action changes the acknowledge alarm image color from red to green. The list is limited to 50 alarms to avoid saving unnecessary data which can cause performance issues. If more than 50 alarms are triggered only the last alarms triggered chronologically are shown.

4.4. Control and Writing Values

For this test, a local OPC UA server was used to avoid any possible disruption to the ongoing process on a real server. Four digital objects connected to four nodes from the server were added to the layout as seen in Figure 22. “valve1_status” represents the state of a valve as a numerical value composed of three bits. The other three digital objects each represent one bit. In this system, “start/stop_v1” corresponds to bit 0, “clean_v1” corresponds to bit 1 and “reset_v1” corresponds to bit 2. The image of each control object is illustrated as a button. When a write command is sent, the image changes to display a pressed button to illustrate the action. To change the valve’s state, first, the valve was started by setting “start/stop_v1” to the ON state by long-pressing on its image and selecting the “->ON” menu displayed. Bit 0 is set to one and “valve1_status”’s value changes to one. Then, the same action was applied to “clean_v1” object and bit 1 was set to 1, thus “valve1_status”’s value changes to three, as both bit 0 and bit 1 are set to one. With each command, the new values are written to the server to update the corresponding node’s value.

4.5. Monitoring Values in a Graph

To monitor the data over a period of time, a graph was created using SurfaceView and Canvas. The user can choose if they want to monitor one or two NodeIds at the same time. This way, values from two NodeIds can easily be compared over a period of time. Furthermore, the user can select the low limit and high limit of the graph to tailor the Y axis scale. An example of monitoring the RPM of a pump over a period of time is shown in Figure 23.

5. Conclusions

In this paper, the development of a portable SCADA system for Android mobile devices was presented. Based on the OPC UA protocol, the application provides a reliable OPC UA Client solution for monitoring and controlling data and building alarms. The application uses a foreground service to facilitate real-time data monitoring even if the mobile device is locked or the application is minimized. Moreover, alarms and conditions were implemented, providing real-time alert notifications that can significantly decrease response times for technical difficulties. The interface’s simplicity makes it an intuitive tool for building monitoring and controlling systems.

By contributing to accessing and efficiently monitoring systems our solution provides extensive options for users, making it adaptable to various use cases. The system’s flexibility allows easy customization, which can meet any number of objectives for the water industry and address any changes which are made to local processes over time. This way, no new resources have to be allocated for upgrading and sustainability is increased. Moreover, its adaptability extends its functionality to various industrial processes. This portable solution can not only decrease resource consumption for transportation through remote monitoring, but also minimizes financial costs by combining all functionalities in one single application. A water company is able to use any custom-made diagrams and provide any vision regarding the local objective to assure the best possible operating environment for the user. This way the sustainability is increased, regarding both efficiency of operation and high coverage. We also expect that the application will be compatible with any future devices which will utilize the OPC UA protocol with the newest specifications, maintaining its relevance and longevity. All the newest OPC UA specifications that are not yet available in the industry were tested and validated with custom-made OPC UA solutions (e.g., open62541 SDK, Node-RED OPC UA node), contributing to the sustainability of the solution.

Evidence is scarce regarding mobile SCADA solutions. In the industry, most solutions on mobile devices are dependent on central SCADA environments, therefore their functioning relates to central gateways, usually without the possibility to adapt or even to implement diagrams. A flexible but much higher cost central SCADA dependent environment is the Ignition Perspective.

The solution was intensely tested. First, the tests covered laboratory scenarios, accessing various OPC UA servers from the PLC level, HMI level, SCADA level and other centralized OPC UA servers or custom OPC UA servers. The laboratory tests proved the solution’s stability and ability to connect and use all accessed services (including A&C alarming). The importance of the laboratory tests, besides preparing for the next testing phase, was that OPC UA A&C services were not yet found implemented in real scenarios, although more than 600 objectives were analyzed in the area of the water operator.

Then, the second testing phase covered real scenarios from the water industry. Due to the large set of water objectives and technologies in the area of the operator, the authors were able to access many types of OPC UA servers and all proved successful in the deployment of small mobile SCADA solutions for various processes.

The time intervals regarding publishing/sampling can be adjusted within the OPC UA client application. It can be set to follow the OPC UA server publishing interval, or it can be adapted to a publishing time interval value. The default value in the OPC UA client is 1000 ms. These options were intensely tested for solutions available in the real scenarios from the industry (e.g., Siemens PLC OPC UA Server, which has an internal polling and publishing strategy) and with custom-made OPC UA servers in laboratories. Some limits of the time intervals could be tested best with an open62541 SDK-based custom-made OPC UA server. For value of 200 ms, which is available for some PLCs’ (e.g., S7-1214) OPC UA Servers’ publishing time intervals, no issues were encountered by the application itself (the consistency of the setting has also to consider the wireless connection types). With the custom-made server, the solution was tested successfully for a 100 ms publishing interval, but the results are not so relevant for the purpose of the application because the tests were made in a wired connection. No smaller values were tested, but the authors focused on smaller time intervals and real-time concepts in work [28]. In addition, the internal sampling interval is set to request values from an OPC UA server. This setting was useful for some types of OPC UA servers, without a high complexity requiring external polling, and for an internal redundancy. This value was set by default to 1000 ms, but the value could be set much lower.

Although the mobile SCADA application was designed for the water sector, the solution is applicable for other industries. OPC UA is an Industry 4.0 key enabler, not only for water [29] but also for other industries [30], and therefore the applicability of the solution is extensive. Furthermore, the need for mobile monitoring in other industries is increasing in many stages of the process lifecycle; from equipment, production line and control solution testing before and during complete local system deployment, towards the operation and maintenance phases.