Operator Dashboards

Operator Menu

Precondition: To open the Operator dashboards menu select Operator from the main menu

• The Operator dashboards menu is opened.

Figure 1: Operator Dashboards

Figure 2: Operator - Responsive desktop dashboards

Machines

Precondition: To open Machines dashboard with full information select:

• As a user with role Operator: Operator/Responsive Desktop
• As a user with role Team Leader: Team Leader/Machines
  • Machines Summary dashboard with full information is opened

The same roles can open the mobile version (lightweight information) of machines dashboard that is developed for tablet devices.

To open Machines Dashboard on tablets select:

• As a user with role Operator: Operator/Machines
• As a user with role Team Leader: Team Leader/Machines Mobile
  • Machines Summary dashboard for tablets is opened

To Machines Dashboard

Downtime

Purpose: Dashboard Downtime shows the information about all machines' downtime in the enterprise for the selected time interval.

Precondition: To open the Downtime dashboard select:

• As a user with role Operator: Operator/Responsive Desktop/Downtime
• As a user with role Team Leader: Team Leader/Downtime
  • It is opened Downtime dashboard.

Downtime: All-time where the manufacturing process was intended to be running but was not due to Unplanned Stops (e.g. breakdowns), or Planned Stops (e.g.changeovers). Downtime is also called Stop Time.

From this dashboard, users can see for the selected time interval:

• Downtime statuses and their periods of all machines in the enterprise during the selected time interval
• Machine downtime is presented with a graphic with different colors for each downtime status; duration in hours and percentage of time
• These unplanned stops are subject to downtime tagging and statistics on downtime tagging times and reasons. They are subject to reports and root cause analysis. Analysis over downtime tagging aids identification of reasons for stop time and supports decision making for addressing issues.

Figure 3: Downtime dashboard

• Machine list could be filtered by selecting All, or separate machines. Filtering machines is also possible by typing in the field part of the name.

Figure 4: Filtering machines in Downtime dashboard

• Custom time range could be changed by selecting intervals from the predefined periods.

Figure 5: Select time period

Figure 6: Downtime chart for machine for the selected time period

Downtime period types are colored with different colors and could be: unplanned, untagged, and OK. Under the graphics are shown total duration in hours and percentage of the selected time period.

• Unplanned (grey) - The time when the machine was not planned to produce, according to the shift calendar. For more details about the shift calendar, refer to the Planned Production Time section. Unplanned time is any time out of the shift or during breaks.

• Untagged (yellow) - A period that is subject to tagging with a downtime reason by the system operator who is responsible to provide an explanation up the chain on the reason why the machine has not been producing in a period when it has been planned to. A low level of production time would mean a high level of downtime, which could be explained by analyzing the top downtime reasons.

• The downtime tagging reasons are grouped into 4 groups:

• Man

  • Meetings, break, lunch
  • Sickness
  • Multi-machine operation
  • Holiday
  • No production planned

• Machine

  • Electric issues
  • Mechanical issues

• Method

  • Setup and/or refill
  • Planned maintenance
  • Testing
  • Correction

• Material

  • Lack of material

  • Lack of tools

    If the user clicks on some Untagged (yellow) period is opened Downtime tagging form to select downtime reason for the whole period (Range Full is selected and From-To are loaded with the date-times for the period and cannot be edited).

    If the user selects option Custom in the Downtime tagging form, the user can change dates and times in the From-To fields and enter a custom period by using date and time pickers.

Figure 7: Select downtime reason for status Untagged

• OK (green) - A period that is not considered as downtime and typically originates from the following machine statuses:

  • Active – the machine is running NC program and doing valuable work
    • Machine offline - There is no connection (ICMP ping) to the machine controller. Usually, this is either due to network-related problems within the manufacturing network, or the machine has been stopped.
    • Machine online – The status appears after a Machine offline status. There is a connection (ICMP ping) to the machine controller, which connection has been restored recently, but status information has not been received after that moment. In this case, the last state in the system could be outdated and hence unreliable.
    • System Offline – There is no heartbeat from a major related system component. The system cannot collect or transport data from the machine to the platform backend. The system malfunction could be either on the gateway, the platform backend, or the Internet connection to the cloud. In case the malfunction is outside the on-premises gateway, data from the machine will be collected and submitted to the cloud as soon as the connection is restored.
    • System Online – The status appears after a System Offline status. There is a heartbeat from all relevant system modules but no status information after that. Hence the machine status information is unreliable as it may have changed during the offline period.

Click here for more details on how to manage downtime reasons.

External Sensors

Precondition: To open The External sensors dashboard select:

• As a user with role Operator: Main MenuOperator/Responsive Desktop/External sensors
  • External sensors dashboard is opened.

On this dashboard are shown charts from different sensors connected to machines or to office rooms.

Figure 8: External Sensors dashboard

Sensors of type Disruptive Technologies

Sensors of type Disruptive Technologies could be connected to machines or rooms tags.

Figure 9: Data from External sensors of type Disruptive technologies

There are min, max, average and current temperatures. Temperatures are shown for the selected time period.

Sensors of type Neuron Sensors

For machines could be configured sensors of type Neuron Sensors for temperatures.

Figure 10: Data from External sensors of type Neuron sensors

Charts show temperature during the selected time interval, min, max, average, and current values.

Sensors of type ReMoni

For machines could be configured sensors of type ReMoni for temperature or power.

Figure 11: Data from External sensors of type ReMoni

Data from the sensors could be visualized by the charts with min, max, avg, and current values for the selected time interval

To see the configuration of tag with external sensor go to Add Tag with External sensor

Maintenance Requests (Basic)

This dashboard is meant to provide operator users access to creating basic maintenance requests. The dashboard button can be found under the Main Menu/Operator

The dashboard is split logically in three sections (Figure 1):

• Context controls - located at the top, this part provides dropdown selection lists for machine and requests severity level. These give the context of the request
• Request - located at the left, this part provides a panel for submitting a maintenance request in the form of a short message regarding the selected context abode
• Active requests - located at the right, this part provides a table panel for reviewing the currently active request for the given context above

Figure 12: Maintenance request dashboard

Submit a Request

To submit a request simply:

• Select the target machine
• Choose the severity of the problem
• Write a short message
• Click on the Submit button

Note
Maintenance requests are managed in groups split based on Severity. Multiple maintenance requests could be submitted for each Severity group. Thus a client could report multiple issues for maintenance which all will be considered active until cleared.

When a request is submitted the following important actions take place:

• the requests is processed within the next 10-20 seconds
• it will be listed in the Active requests section on this dashboard
• it will be registered as an Active Alarm for the target machine
• it will also be accessible by the Client's Service Company organization which can initiate appropriate actions
• configured notifications will be sent to the interested parties based on the severity of the request

Clear Active Maintenance Requests

After the reported problem has been resolved the Client must clear the maintenance by sending the system message "Normal" for the target Severity. This gives the means to manage multiple maintenance requests in parallel based on the severity.

Example:

1. Submit two requests with severity Medium for machine 1
2. Submit one request with severitu Low for machine 1
3. At this point for machine 1 there will be three active maintenance requests: one with low severity and two with medium severity
4. After the low severity issue is resolved, submit "Normal" as message for severity Low
5. Low severity requests are cleared. Now for machine 1 there will only two active maintenance requests with medium severity
6. After they have also been resolved, submit "Normal" as message for severity Medium
7. All maintenance requests have been cleared