Policy for auto-generating stop events
There's a fine line that divides between what's to be considered an inherent delay in the production process, to what's considered an actual machine stop in which the machine is not working when it should be working. The system auto-generates stop events per the policy of what will be considered a short stop event (a.k.a. 'micro event'), and what will be considered to be any other stop event. See Configuring Stop Event Generation for information on how to configure the policy for auto-generating stop events.
The combination of the micro stops policy with the general configuration of what will be registered as any other stop event, is that client's overall policy for when Matics should auto-generate stop events. It determines the meaning of that time in which the machine wasn’t working. These stop events are indicated visually in various contexts on the timeline widget (hovering over the stop event provides more information and options).
Why report stop event reasons?
It's important to report what caused the stop event, and this is done by assigning to the event its reason. Reporting stop event reasons results in robust production analyses which are used to improve future planning. Best practice is to report the reason in real-time. Notwithstanding, there's also the option of retroactive reporting. Sometimes the stop event started for one reason but continued due to a different reason. In this case, the person reporting stop event reasons would split the stop event to its different segments and assign to each the correct reason.
Detected micro events are automatically tagged as such, without issuing the report stop event prompt. This both reduces visual noise and makes the operator's job easier since operators aren't expected to deal with reporting stop event reasons for such short stops, while in the background all this data is aggregated and can be very useful. For example, successive micro stops may indicate issues with the machine. Other stop events are also automatically logged, but are not tagged with a reason since the reason needs to be reported.
TIP
After opening a service call, the following stop events--up to the completion of the service call--will be auto-classified with the stop reason reported when opening that service service call, if thus configured.
Who reports stop event reasons?
On the production floor, machines are usually assigned operators and these operators will see the stop event alert in real-time and are expected to report the reason. As in all scenarios, retroactive reporting is also an option. Shift-managers and production managers may also find it useful to report or examine stop event reasons.
Where are stop event reasons reported?
Stop event reasons can be reported through all Matics apps, in different contexts of machine, department, or site. The context determines the available reporting period.
From where the Matics user decides to report stop event reasons, depends on the role that user fills and which devices are available to that user.
Where do machine operators report stop events?
Machine operators will use the Operator app running on the tablet if the site is using tablets on the production floor. The tablet may be dedicated to a single machine, or it can be configured to serve multiple machines. This latter configuration is usually implemented when a single operator operates multiple machines.
Operators using the tablet report stop events through the stop events screen. When the stop event occurs, operators are presented with the options for immediate reporting (if they don't report the reason promptly, this window closes automatically after a short interval).
NOTE
Some sites prefer to disable the option of displaying the report stop event dialog when a stop event is generated.
For retroactive reporting there are Stop event logs conveniently located in the expanding side-panel, as well as the production lines' event log. Logs provide the list of all the current stop events, and operators can check if there are stop events that they haven't reported the reason for.
In the Operator app there's also an option of using a shortcut widget. All these options are described in this article.
Splitting stop events in order to assign the correct reason to each segment of the event is described in this article.
Using the Web app (not tablets) is also an option if computers are available for use by operators on the production floor. When using the Web app, operators will most likely use the machine's Main page for reporting stop events.
Where do shift managers / production managers report stop events?
Shift managers / Production managers using tablets, will tap the machine in the Shift Manager Dashboard and in the selected machine's page use either the Stop event logs conveniently located in the expanding side-panel, or the production lines' event log for retroactive reporting. All of these options are described in this article.
Splitting stop events in order to assign the correct reason to each segment is described in this article.
Managers using the Web app will find that reporting stop event reasons is very easy through the Online dashboard of each department, in which they can easily hop from one machine to the other.
Reporting the same reason for multiple events is often done through logs, which provide multiple filtering options to easily list all the events that should be tagged with the same reason. The tablet logs were mentioned above, and in the Web app there are the machine level logs both in the Operation tab and the Events tab. For those interested in a higher-level log, there's the site-level stop events log that logs events for all machines for the selected period scope. Here managers can examine stop event patterns and maybe correct or fine-tune existing reporting
To correct or examine historic reporting, managers can use the events history report.
Finally, managers may use the Manager app for either reporting stop event reasons directly, or for monitoring reporting performance and if stop reasons aren't being reported, encourage operators to do so.
How to report stop event reasons?
Reporting stop event reasons from the tablet
Reporting a production line's stop event reasons
In production lines there's the inherent dependency between machines. A stop in one machine will impact the production in other machines. If this configuration is enabled, the system will tag the event in which the stop originated as the root event and link subsequent stop events to the initial stop. Reporting the stop even reason for the root event will automatically apply the reason to all linked events, for reporting efficiency.
Reporting stop reasons from the Online dashboard
Go to Production Floor > Department view [selected department] > Online.
In the Online tab, click the actions menu of the target machine and choose Report Stop Event.
A list of all the machine's logged stop events will be displayed. Select those events for which you want to enter or change the stop reason to the reason you will soon set.
Click the Report Stop Event control which is now visible (the control isn't visible until you select an event record from the list).
In the Stop events dialog select the event group and event reason.
Click Save.
Reporting stop reasons from the site-level stop event log (multiple machines)
Go to Production > Reporting Stop events.
(optional) Filter the log to present relevant events.
Select those events for which you want to enter or change the stop reason.
Click the Report Stop Event control.
In the Report Stop Event dialog select the event group and event reason.
Click Save.
Reporting stop reasons from the machine's stop event log
Click the machine's name hyperlink (wherever you are in the system).
In the machine's page, click the Events tab.
(optional) Filter the log to present relevant events.
Select those events for which you want to enter or change the stop reason.
Click the Report Stop Event control.
In the Report Stop Event dialog select the event group and event reason.
Click Save.
Going back in history to report stop event reasons
When reporting stop events through system reports you can go back in history to search for events (all history is saved). The system's initial default loading of 10,000 records is for efficiency.
Note: Inputting the stop reason in this context is done for each event individually.
Go to Reports > System Reports.
Click index #4, History.
Click index #26, the 5.01 Events in a shift report.
(Optional yet recommended due to the amount of data) Apply a filter.
Click Search after applying search criteria.
In the table of search results, click the index number of the event.
In that event's page, first select the event group from the Event Group list and then the event reason from the Event list.
Click Save Changes.
Reporting stop events from the Manager app
Tab the machine in the department page.
In the machine's page:
Tap the Shift tab and then tap Stop events. OR
Tap the Machine log tab and then tap Stop events.
Tap to select the event(s) for which you want to report the reason. (You can filter the list if needed.)
Tap Report events, or tap Edit reason if this event already has a reason reported for it and you need to correct it.
Select the stop event reason from the relevant event group.
Tap Report.
Adding comments when reporting the reason
The option to add informative comments when reporting a stop event's reason is available in two contexts:
In the Operator app and in the machine's Main tab. These notes will be visible in the event logs, as well as in the event's dialog that opens when clicking the event in the timeline widget.
Splitting stop events
Split events retroactively for accurate fine-tuning of logged stop events' reported reasons.
For example, you left for a planned break, but when you returned the machine wouldn't start up because of a broken part. So after the planned break the machine was inactive due to pending maintenance. If you don't split the planned break event to report how much time the machine was stalled for each reason, valuable information is lost.
When splitting events retroactively, you first split the event and then report its stop reason.
Splitting stop events is available in any context that you can report stop events.
The control differs per the context. In the event logs it'll be provided as a Split event retroactively control. In the tablet it is the scissors control, while in the Manager app and the Web app's Machine Operation tab it is:
TIP: The split control is only active when a single event is selected.
To split a stop event reason:
From the list of events, select the the stop event.
Click the split control, which is now active or visible.
In the split event dialog:
Click the calendar widget. Select the split date, the time the event split and click OK.
Click Save to apply the split and close the dialog.
The split event is now added to the stop events list with the event group and event reason of the originating event. Select it and click the Report Stop Event / Report events control to apply the correct event group and event reason.
NOTE: If you're splitting an ongoing event, there will be no end time for the split until it eventually ends. The start time of the split event is the time you tap SPLIT. The originating event's end time will be that time too:
