Gathering of process variables

Before visualizing the process, the adequate variables must be collected from the devic-es. Robot controls all the processes in the cell. Thus, gathering of the variables takes place via robot REST interface accessing directly for according variables in robot IO system’s EthernetIP adapters. Additionally, the overall Supervisory status of the cell is monitored with robot’s own RAPID program variables for controlling the questioned process. Regardless of the monitored process or monitoring the production at the Super-visory level, functionalities and the order of the operations are identical. Steps which are taken from the initial launch of the monitoring, for reaching the moment when the data is send to IoT-Ticket data server can be portrayed in the Figure 21. These steps are

de-tailed in following paragraphs concerning the monitoring of the production at Supervi-sory level, included with few words over the basis of the process monitoring.

Figure 21. Flowchart for Real-rime process monitoring

Steps, portrayed in the Figure 21, are higher-level notifications of the software compo-nents used to perform the functionalities. Before continuing to description level of these operations, a following figure can be noted. Figure 22 portrays the program architecture deployed in TUT-AM-EC2 instance for collecting the variables and transposing them into IoT-Ticket platform.

Figure 22. Program architecture for Real-time process monitoring

Portrayed in the Figure 22 the entirety of the process monitoring can be realized as one independent component (Real-time Monitoring), composed from several individual software components acting together by program calling and using dependencies from outside services with REST interface. During the implementation, a future prospect of shifting the programmed backend environment to be executed within resources of an alternative service provider was kept in high value. For this reason, the individual op-erations where heavily modulated. All the modulated components inside the main com-ponent, are deployed in one folder inside TUT-AM-EC2 instance. The main module is executed with Node.js forever npm-module for evading rebooting of the instance. In the following, functions of specific components are detailed.

mainMonCon.js is the main component launched at the start of the Real-time monitor-ing. It holds all the sub-functions for calling appropriate operations for the monitormonitor-ing.

After the start, according component instantly calls runProductionMonitor function and is left waiting for commands via IoT-Ticket Dashboard REST API (Commands REST API) which is used when launching CMT monitoring or COAX monitoring functions.

IoT-Ticket Dashboards are configured to hold button elements for initiating a monitor-ing for accordmonitor-ing process (see Chapter 4.3.2 for details). By pressmonitor-ing these elements user sends a HTTP POST request with HTTP basic authentication to TUT-AM-EC2 instance for activating the monitoring. With similar elements, a user can stop the moni-toring. Questioned requests are described in Table 9. Furthermore, this component has logging capabilities with time and date record for later debugging the activities. Similar debugging is also available with all the other components portrayed in Figure 22. Log-ging was performed with log4js module. log4js was selected from the reason that it holds interface for logging inside Loggly service [171]. Loggly is a cloud based logging

management service where logs are able to be accessed and studied online via Loggly web pages [172].

Table 9. HTTP request for controlling the monitoring

Function URI

base-URI: http://TUT-AM-EC2-Elastic IP:PORT/

Method

Start CMT process monitoring cmt/startmonitor POST

Stop CMT process monitoring cmt/stopmonitor POST

Start COAX process monitoring coax/startmonitor POST

Stop COAX process monitoring coax/stopmonitor POST

runProductionMonitor function is launched at the start of the mainMonCon.js. Func-tion is left running with timeout interval of 3 seconds, which becomes the update inter-val for these gathered variables. Function controls the additional components for moni-toring of the production inside entire application level (Supervisory level).

There are couple of reasons for dividing the functions and components in the form as described in Figure 22 is that different components are handled with distinct timeout intervals. These timeouts are represented in the questioned figure with millisecond rec-ords above the function. Timeouts can more easily be handled at the upper level of the architecture than encapsulating within individual components. Production can be moni-tored with less frequency than the processes itself. Use of the production monitoring is to give a user basic information over the running application, concerned information is detailed in Chapter 4.3.2. Additionally, the lower level components can easily be main-tained and modified.

runCMTprocessMon and runCOAXprocessMon -functions are launched when the user requests for according process monitoring via IoT-Ticket Dashboard elements.

These functions are driven with 250 millisecond timeout interval and them use moni-torCMT and monitorCOAX components. Compared to foregoing functions sendCMTprocessToIoT and sendCOAXprocessToIoT are called with 500 millisec-ond timeout interval. These two functions control the data sending for IoT-Ticket Data Server which holds maximum of 500 millisecond update interval. Thus, variables itself are updated within backend service with higher frequency for gaining more accurate data ready for to IoT-Ticket provision.

monitorProduction component is used by runProductionMonitor function for First;

preparing the data model for accessing robot variables via Robot REST API and Sec-ond; storing requested variable data with JSON format within the component. Compo-nent uses the pre-prepared JSON data structure where the URI’s for desired robot varia-bles are stored (see Table 10 for details). These URI’s are transposed for sub-component of methods where requestRobotParam function sends the HTTP GET request with

specified URI, by npm request module for Robot REST API. In the case where the ses-sion is not established, robot returns with HTTP error code 401, not authenticated.

Component responses with function methods.authenticate and returned digest authenti-cation cookie is stored in the component’s cookie-jar for later accessing the API. When the authentication is verified, responses from requesting the variable states are stored in JSON structure. In the case where additional formation of the returned variable is need-ed it is handlneed-ed before storing. This enables immneed-ediate later transpose of the variable data for IoT-Ticket Data Server.

Table 10. Robot variable URI’s for monitoring the production

base-URI:

http://robot-ip-address/rw/rapid/symbol/data/RAPID/T_GUI/CellData

Name resource-URI Datatype (IoT-Ticket) Unit (IoT-Ticket)

timeETA /sTimeETA?json=1 String Text

currUser /sCurrUser?json=1 String Text

process /sProcess?json=1 String Text

procedure /sProcedure?json=1 String Text

details /sDetails?json=1 String Text

platformID /sPlatformID?json=1 String Text

fixture /sFixture?json=1 String Text

timeStarted /sTimeStarted?json=1 String Text

prodAvailable /bProdAvailable?json=1 Boolean bool

Current implementation is though a narrow introduction for the subject and for this rea-son, each device inside IoT-Ticket data structure (under the enterprise level) in added manually via specifically formed JavaScript code. From the response of the new device formation, an identification number is grasp and stored in JSON file, devices.json. Path of the each Datanode is established by the user and them are stored by IoT-Ticket server each time current Datanode-path combination is initially written to data server (see Chapter 3.4.1 for details). These Datanode-path combinations remain evermore the same. Thus, them are saved in another JSON file, datanodes.json. Datanodes file holds the name of the node, path for the node, unit of the node and datatype of the according node. Glimpse of the file is portrayed in below lines of JSON structure.

"prodTimeETA":

Both the devices.json and datanodes.json are accessed by the writeProdDataToIoT component. Initially current component assembles a JSON structure, which is a combi-nation of variable data stored by monitorProduction component, and Datanode infor-mation from datanodes.json. Data and inforinfor-mation are stored in secondary JSON struc-ture in a way that all the retained data can be send within one single message. A glimpse of the mentioned structure is illustrated below this paragraph. Together with device ID and the formed data structure mentioned component uses methods.writeToIoT function for sending the data to IoT-Ticket data server. methods.writeToIoT holds authentica-tion informaauthentica-tion, method (POST), headers and the base URL for accessing the data server. Final URL is formed from the base URL and from JSON structure (path) trans-posed from writeProdDataToIoT with component call.

var dataToWrite = [{

"name": datanodesJSON.prodTimeETA.datanode, "path": datanodesJSON.prodTimeETA.path, "v": productionData.timeETA,

"unit": datanodesJSON.prodTimeETA.unit, "dataType": datanodesJSON.prodTimeETA.dataType }, "dataType": datanodesJSON.prodCurrUser.dataType }

. . .]

When monitoring one of the process (CMT or COAXwire) data model and the data flow takes similar steps as described above. Difference comes only from the initial op-eration where user need to activate the monitoring via IoT-Ticket Dashboard, for the timeout interval of the data update and for the gathered variable data from the robot. For these reasons, detailed operations for process monitoring are not described. Yet, viewer can find the names and the specific Robot URI’s for gathered variable data in Appendix B.