METHOD AND A SYSTEM FOR TRACKING THE DOWNTIME OF A PRODUCTION MACHINE

Abstract

A method for tracking the downtime of a production machine (12) comprises the steps of: Receiving sensor data (SD) from the production machine (12) and production target data (PTD), Combining the sensor data (SD) and the production target data over a certain period (40) providing combined data (D) and calculating characteristic data (CD) of the combined data (D), Determining if the combined data (D) is from a downtime period (44) of the production machine (12) based on the characteristic data (CD), and Characterizing the downtime period (44) using a machine learning module (48) implemented in the control unit (32), the machine learning module (48) providing a reason (R) for the downtime period (44) as an output value. Further, a system (19) for tracking the downtime of a production machine (12) is shown.

Claims

1. A method for tracking downtime of a production machine, the method comprising: continuously receiving, by a control unit, sensor data from the production machine and production target data, combining the sensor data and the production target data over a certain period providing combined data and calculating characteristic data of the combined data by the control unit, determining if the combined data is from a downtime period of the production machine based on the characteristic data, and characterizing the downtime period using a machine learning module implemented in the control unit, wherein the machine learning module provides one of a set of predefined reasons based on input values, wherein the predefined reasons are taught to the machine learning module through training, the machine learning module receiving the characteristic data of the downtime period as an input value and providing a reason for the downtime period as an output value, wherein the control unit stores the downtime period and the downtime period characterization time-resolved, and wherein, in case the downtime period is caused by a specific component of the production machine, the machine learning module additionally provides a respective identifier of the component of the production machine causing the downtime of the production machine.

2. The method according to claim 1, wherein the control unit only considers these periods as downtime periods in which the production of the production machine has stopped for at least one minute, in particular for at least three minutes.

3. The method according to claim 1, wherein the control unit additionally receives event data from the production machine and provides the event data additionally to the machine learning module as an input value.

4. The method according to claim 1, the reason being one of an idle time, an out of production schedule, an equipment defect, a shop floor process defect, a maintenance or cleaning of the production machine, a setup of the production machine, or an unknown reason.

5. The method according to claim 1, wherein the characteristic data comprises at least one of the following values: a time since the last production of the production machine, a time since the last downtime period of the production machine, and/or a productivity of the production machine in the respective period.

6. The method according to claim 1, wherein the combined data of subsequent periods comprises a temporal overlap.

7. The method according to claim 1, wherein the control unit stores the downtime periods and their characterization time-resolved, wherein a display is assigned to the control unit and wherein the control unit shows a visual evaluation of the downtime periods on the display.

8. The method according to claim 1, wherein the control unit additionally provides an expected duration of the downtime of the production machine.

9. The method according to claim 1, wherein the control unit additionally performs the following operations to determine a setup of the production machine: tracking the current job identifier of the production performed at the production machine, detecting a change in the current job identifier, and characterizing the downtime period as a setup period in case the length of the period is within a certain time range.

10. A system for tracking the downtime of a production machine, the system comprising: a production machine processing a product according to production target data, the production machine having at least one sensor providing sensor data, and a control unit receiving continuously the sensor data from the production machine, the control unit being adapted to perform the method according to claim 1.

11. The system according to claim 10, the production machine being one of a printing machine, a die-cutting machine, a hot foil stamping machine, a folding-gluing machine, or a litho-laminating machine.

12. The system according to claim 10, the system comprising at least one additional production machine processing a product according to production target data, the at least one additional production machine having at least one sensor providing sensor data, wherein the control unit continuously receives the sensor data from the at least one additional production machine and characterizes the downtime periods of all production machines.

Description

[0046] Further features and advantages of the invention will be apparent from the following description of two embodiments with the aid of the enclosed drawings, in which:

[0047] FIG. 1 a schematic block diagram of a system according to a first embodiment of the invention,

[0048] FIG. 2 a schematic block diagram of a method according to the invention performed with the system of FIG. 1,

[0049] FIG. 3 a schematic representation of the calculation of characteristic data in an period in a step of the method of FIG. 2,

[0050] FIG. 4 an illustration of possible output values provided by a machine learning module used in the method of FIG. 2,

[0051] FIG. 5 possible graphical representations of analysis of the tracked downtimes of the system of FIG. 1, and

[0052] FIG. 6 a schematic block diagram of a system according to a second embodiment of the invention.

[0053] FIG. 1 shows a system 10 comprising two production machines 12 and a central unit 14.

[0054] Each production machine 12 has several components 16 and several sensors 18 and is adapted to process a product 20 according to production target data PTD provided by central unit 14.

[0055] To be precise, each production machine 12 processes product 20 with its components 16.

[0056] Sensors 18 monitor the current state of the respective production machine 12 and provide corresponding sensor data SD. The sensor data is fed continuously to the central unit 14 via a data cable or a wireless communication.

[0057] For instance, sensor data SD may be transferred to central unit 14 via a WLAN or a Bluetooth connection.

[0058] In the shown embodiment, production machine 12 is a flexographic printing machine 22 and product 20 is a sheet 24 of paper.

[0059] The components 16 of printing machine 12 are an ink tray 26, an anilox roller 28, and a printing roller 30.

[0060] In a known manner, anilox roller 28 takes up ink from ink tray 26 through a rotational movement and transfers the ink to the printing roller 30. Printing roller 30 subsequently transferring the ink onto sheet 24.

[0061] Accordingly, the processing of product 20 is not shown embodiment the printing of forms onto sheet 24.

[0062] It has to be understood that FIG. 1 is only illustrative in nature and that there are typically more than the shown components 16, i.e. a printing machine 22 has typically several ink trays 26, anilox rollers 28, and printing rollers 30.

[0063] In general, production machine 12 may also be a die-cutting machine, a hot foil stamping machine, a folding-gluing machine or a litho-laminating machine.

[0064] In the embodiment of FIG. 1, the two production machines 12 are of the same type, i.e. those production machines are printing machines 22.

[0065] Production machines 12 however may also be of different types. For instance, the first production machine 12 may be a printing machine 22 and the second print production machine 12 a folding-gluing machine further processing product 20 processed in the first production machine 12.

[0066] Moreover, system 10 may comprise a plurality of production machines 12.

[0067] To increase productivity of system 10, system 10 is adapted to track the downtime of production machines 12. For this purpose, central unit 14 has a control unit 32.

[0068] More specifically, control unit 32 comprises a data medium 34 and a computing unit 36, the data medium 34 having stored therein a computer program which is executed on computing unit 36 and which comprises program code means to track the downtime of production machines 12.

[0069] For this purpose, control unit 32 uses a method shown in the block diagram of FIG. 2. In the block diagram, solid boxes represent logical blocks of control unit 32 and dashed blocks are hardware components, i.e. the physical components of system 10. Furthermore, arrows indicate data streams between the software and/or hardware components of system 10. For reasons of simplicity,

[0070] In a first step, control unit 32 continuously receives the sensor data SD from the sensors 18 and additionally the production target data PTD. This data is continuously stored in a volatile or non-volatile memory of control unit 32.

[0071] Subsequently, a pre-processing module 38 combines the sensor data SD and the production target data PTD in periods 40 with a certain length (FIG. 3).

[0072] In the shown embodiment, the length of each period 40 is 10 minutes and subsequent periods 40 overlap in a window of five minutes, that is the last 50% of the previous period.

[0073] It has to be understood that the length of the time periods 40 and also the length of the overlapping time periods is illustrative in nature. Therefore, the total length of a period 40 may also be shorter or longer (for instance 5 or 15 minutes) and the length of the overlapping period may also be shorter or longer (for instance the last 25% or 75% of the last period).

[0074] Pre-processing module 38 additionally calculates characteristic data CD (FIG. 2) for each period 40.

[0075] As an example, preprocessing module 38 calculates the time since the last producing period of production machine 12, a time since the last downtime period of production machine 12 and\or the productivity of the production machine 12 in this period 40.

[0076] The productivity of the production machine 12 may be provided as a percentage value with respect to the maximal possible productivity of the production machine.

[0077] In other words, if production machine 12 is processing products 20 at full speed in eight minutes out of the ten minutes and in the other two minutes is idle, pre-processing module 38 would calculate a productivity value of 80%.

[0078] Additionally, pre-processing module 38 determines specific events E from the sensor data and provides corresponding event data ED.

[0079] In a next step, pre-processing module 38 feeds characteristic data CD and event data ED to a classification module 42.

[0080] Classification module 42 determines based on characteristic data CD and based on event data ED if production machine 12 was processing products 20 in the respective period 40.

[0081] In other words, classification module 42 classifies the respective period 40 as a downtime's period 44 or as a producing period 46 (FIG. 4).

[0082] For instance, classification module 42 classifies a period 40 as a downtime period 44 in case the productivity of the respective period 40 was below 50% or in case the time in which production machine 12 was not processing any products 20 laws larger than three minutes.

[0083] In case classification module 42 has detected the presence of a downtime period 44, the characteristic data CD and the event data ED is fed to a machine learning module 48 of control unit 32.

[0084] Machine learning module 48 comprises at least one neural network which was trained to provide a reason R and an identifier ID as output values for the data provided as input value.

[0085] In other words, machine learning module 48 provide a reason R 40 is downtime of the production machine in the downtime period 44 and the identifier ID of the component 16 causing the downtime of production machine 12 (FIG. 4).

[0086] In particular, machine learning module 48 provides one the following reasons R. Additionally, an example is given for each reason. [0087] Idle time (A planned period in which production machine 12 should not process any products), [0088] Out of production schedule (Production machine 12 was not able to process any products in the downtime period 44, for instance because corresponding product 20 were not available for production machine 12) [0089] Equipment defect (A component 16 of production machine 12 broke or indicated an error, so that processing of products 20 had to be stopped in the downtime period 44), [0090] Shop floor process defect (A paper jam was detected and an operator of the production machine had to resolve the paper jam), [0091] Maintenance/cleaning (The quality of the forms printed on paper 24 was detected to be not good enough, so that printing roller 30 off printing machine 22 had to be cleaned), [0092] Setup (A new print job started and a new ink has to be filled into the ink tray 26), and [0093] Unknown (All other downtime periods 44).

[0094] In case the downtime period 44 is caused by a specific component 16 of production machine 12, machine learning module 48 to provide also the respective identifier of this component 16: In all other cases the machine learning module provides an unknown-tag.

[0095] The identifier ID of the component 16 causing the downtime and the reason R are subsequently fed to an analysis module 50 of control unit 14.

[0096] Analysis module 50 stores the identifier ID and the reason R and calculates the duration of the specific downtime time-resolved in the data medium 34.

[0097] Accordingly, analysis module 50 builds up a database with downtimes of production machine 12 and their duration, so that analysis module is adapted to provide an expected length of the current downtime.

[0098] For instance, analysis module 50 searches in the database for entries with the same reason R and the same component identifier 16 and provides a mean values of all the found entries as the expected duration of the downtime.

[0099] Moreover, analysis module 50 is also adapted to provide a validation of the reason R in case the ma

[0100] For this purpose, analysis module 50 executes the following steps: [0101] Tracking a current job identifier of the production performed at production machine 12, [0102] Detecting a change in the current job identifier, and [0103] Providing the reason R “setup” for the downtime period 44 in case the length of the period 44 is within a certain time range.

[0104] In other words, a threshold value for the length is stored in the data medium 34 and the analysis module validates the reason R of the machine learning module.

[0105] In case machine learning module 48 and analysis module 50 provide different reasons for a certain downtime period 44, the reason for this downtime period is changed to “unknown”.

[0106] It is also conceivable that analysis module 50 executes the aforementioned steps for all outputs of machine learning module 50.

[0107] Subsequently the control unit 32 displays a graphical analysis 54, 56 (FIG. 5) of the tracked downtimes on a display 52 of the control units.

[0108] The first analysis 54 provides a temporal overview of periods 58 in which no production was planned and of periods 60 in which a production was planned. These periods 58, 60 are taken from the production target data PTD.

[0109] For each period 60 in which a production was planned, the duration of periods 46 in which production machine was actually producing and the duration of downtime periods 44 is illustrated.

[0110] In the second analysis 56, a total number of occurrences of the reasons for the downtime and the corresponding summed duration of downtimes for each reason R is shown in a pie chart.

[0111] This way, an easy analysis and tracking of the downtimes of the production machine 12 is provided. In particular, an operator of the machine simply sees the reason R causing the timewise largest reason R for a downtime of production machine 12.

[0112] In general, it is conceivable that detailed information on downtime periods of a specific reason is provided on display 52 in case an operator of production machine 12 selects a specific reason R, for instance by clicking onto the specific reason R.

[0113] In FIG. 6, a second embodiment of system 10 is shown in a similar block diagram as in FIG. 1. The system 10 of FIG. 6 essentially corresponds to the system 10 of FIG. 1 so that only the differences between the first and the second embodiment will be discussed in the following. Identical and functionally identical components are provided with the same reference signs.

[0114] Compared to the system 10 of FIG. 1, the control unit 32 is not integrated into a central unit, but integrated into production machine 12.

[0115] Accordingly, each production machine 12 of a production plant may be provided with its own control unit 32.

[0116] However, it is conceivable that all of the control units 32 are connected to each other and/or provide their data to the central unit.

[0117] Moreover, the downtime data of different production plants may also be shared between the different production plants by up- and downloading the respective data to central servers.

[0118] Regarding idle time, there are currently three steps. First, an analysis on the equipment's activity over a period of at least two months is used to automatically detect repetitive breaks occurring during production. Then, for each equipment where a repetitive break is found, a signature is created. Finally, every time a downtime occurs, it is then matched against those signatures to find if they correspond to the “Idle time” category.

[0119] Steps 1 and 2 are done offline, need to be applied on new equipment once it has produced for at least month and preferably for 2 months, and rerun on old equipment every couple of months for more up-to-date data. “offline” here refers to an algorithm runs with all the data available from the start, as a non-live activity.

[0120] Step 3 is done online and in real time, in the same pipeline as for the setup detection. “online” here refers to an algorithm which processes data piece-by-piece as it arrives in the cloud live.

[0121] Step 1

[0122] The goal of step 1 is to flag intervals of time in a week when regular breaks from production occur.

[0123] The data used for this step comes from the telemetry in our cold storage.

[0124] However, the same result could be obtained with machine events from the cold and warm storages with little adjustments.

[0125] The following operations, in order, are applied to the data:

[0126] 1) Find the Availability: [0127] a) Anomaly filtering (missing data for example) [0128] b) Resampling of the data to have one point per 5 minutes [0129] c) Switch of data to absolute to relative [0130] d) Clipping of data between 0 and 1

[0131] 2) Using Availability, Clean Data: [0132] a) Compute median availability [0133] b) Locate downtime intervals using median availability [0134] c) Filter out long downtimes (more than 1 hour) [0135] d) Filter out short downtimes (5 min or less)

[0136] 3) Compute Daily Availability: [0137] a) Group filtered/clean data by minute and hour

[0138] 4) Find Frequent Breaks [0139] a) Compute median daily availability [0140] b) Locate idle periods using half of median availability [0141] c) Filter out long idle periods (more than 1 hour) [0142] d) Filter out short idle periods (5 minutes or less)

[0143] Step 2

[0144] The goal of step 2 is to create a signature for each valid idle period found in part 1. The signature comprises of variables such as: [0145] The average duration of the break [0146] The variability of duration between occurrences [0147] The variability of when the break happens between occurrences

[0148] The data used for this step is the output of step 1, as well as the input data of step 1.

[0149] The following operations, in order, are applied to our data:

[0150] 1) Extraction of Downtime Intervals from Telemetry [0151] a) Use machine state data to find downtime intervals [0152] b) Filter out long downtimes (more than 1 hour) [0153] c) Filter out short downtimes (5 min or less)

[0154] 2) Create Statistics for Each Idle Period Found in Step 2 [0155] a) Select all downtimes that intersect the idle period [0156] b) Compute the 0.85-HDR (Highest Density Region) of the idle time density function [0157] c) From the HDI above, extract the variability of when the break happens [0158] d) From the selected downtimes, compute the mean and standard deviation of the durations

[0159] Step 3

[0160] The goal of step 3 is to use the signatures, created in step 2, to categorize the downtimes as idle time. This step is straightforward: when the micro-service is asked to categorize a downtime, the downtime goes through the same series of checks as before, and if a signature exists for the corresponding equipment, a new algorithmic pipeline is run in parallel to the other algorithms (setup for example).

[0161] In the algorithmic pipeline for the idle time, the middle of the downtime is matched against the signatures, if a match is found (there can be at most one by construction), the duration is then compared to the signature. It needs to be within one standard deviation of the mean duration for the pipeline to return a positive match.

[0162] If the idle time algorithmic pipeline matched, the micro-service returns the same downtime but with a predicted category of “Idle time”. Only a match from the setup pipeline trumps.