Methods and systems for tracking downtime of production machines
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- BOBST MEX SA
- Filing Date
- 2023-05-08
- Publication Date
- 2026-06-30
AI Technical Summary
Existing technologies make it difficult to gain a deep understanding of the reasons for machine downtime, making it difficult to effectively reduce downtime and affecting the overall productivity of the production plant.
By using machine learning modules to analyze sensor and event data from production machines, downtime periods are identified and causes are identified. Combining feature data and threshold judgments, random forest and XGBoost algorithms are used for classification, enabling accurate tracking and cause analysis of downtime.
It enables precise tracking and root cause analysis of production machine downtime, improves the overall productivity of production machines, provides an easy-to-use downtime tracking method, and can quickly respond and recommend component replacements to reduce downtime.
Smart Images
Figure CN117032090B_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to a method and a system for tracking downtime of production machines. Background Technology
[0002] In a manufacturing plant, downtime of production machines can have a significant impact on the overall productivity of the plant.
[0003] Therefore, operators in these types of production plants generally want to minimize downtime of production machines. However, this requires understanding the specific reasons for the downtime of the production machines.
[0004] US2006 / 149407A1, WO2019 / 199674A1, and WO2005 / 017635A1 disclose general methods for realizing productivity-related information. Summary of the Invention
[0005] Therefore, the object of this invention is to provide a simple possible way to gain a deeper understanding of the causes of downtime in production machines.
[0006] To achieve this objective, the subject matter of claim 1 provides a method for tracking downtime of production machines. The method includes the following steps:
[0007] a) The control unit continuously receives sensor data and production target data from the production machine.
[0008] b) Combine sensor data and production target data within a certain time period to provide combined data, and have the control unit calculate the characteristic data of the combined data.
[0009] c) Determine whether the combined data originates from the downtime period of the production machine based on the feature data, and
[0010] d) Use a machine learning module implemented in the control unit to characterize the downtime period. The machine learning module receives feature data of the downtime period as input value and sets the cause of the downtime period as the output value.
[0011] This invention is based on the discovery that machine learning modules can be used to track downtime of production machines. To this end, data related to the production machines is preprocessed and provided to the machine learning module in a specific format. The machine learning module then provides one of a set of predefined causes based on the input values. By appropriately training the machine learning module, the predefined causes are taught to it. This provides a system that can also react to new and unknown situations. Therefore, the operators of the production machines do not need to classify the causes of downtime periods themselves, providing an easy-to-use method for tracking downtime of production machines.
[0012] For example, the machine learning module could be an ensemble of Random Forest and XGBoost. This combination has proven to be very effective in identifying the causes of downtime in production machines.
[0013] The Random Forest algorithm, also known as the Random Decision Forest, is an ensemble learning method for classification, regression, and other tasks. It operates by constructing a large number of decision trees during training time.
[0014] In addition, XGBoost provides a regularized gradient enhancement framework, which significantly improves computation speed.
[0015] Sensors on the production machine continuously monitor its current status, with each sensor providing corresponding sensor data.
[0016] For example, the operating speed, total operating time, total number of actions performed, and / or time since the last downtime of each individual component of the production machine are monitored by corresponding sensors, and the resulting sensor data is provided to the control unit.
[0017] Generally speaking, it can be envisioned that the control unit that tracks the downtime of the production machine is part of the corresponding production machine.
[0018] Alternatively, the control unit can be integrated into a central control unit in the production plant, allowing the control unit to monitor the downtime of multiple production machines. In this case, the control unit is connected wirelessly or via cable to each sensor.
[0019] Furthermore, by using thresholds for specific parameters of the feature data, decision trees can be used to determine whether combined data comes from downtime periods.
[0020] Alternatively, another decision tree with another machine learning module can be used to determine whether the combined data comes from the downtime period.
[0021] According to one aspect of the invention, the control unit may consider these time periods as downtime periods in which production has ceased for at least one minute, and particularly at least three minutes. In practice, it has been proven that these periods in which the production machine stops its production for more than one minute or more than three minutes are particularly relevant to improving the overall productivity of the production machine.
[0022] The control unit can additionally receive event data from the production machine and provide this event data as additional input to the machine learning module. Events such as the opening of a lid or the replacement of a component are reliable indicators of the existence of a corresponding situation. Therefore, it has been proven that the machine learning module provides the correct cause more reliably when event data is used in addition.
[0023] In this paper, event data refers to specific events related to the operation of production machines. Compared to sensor data, event data includes individual events during the product processing.
[0024] For example, event data may be related to ink replacement, ink reservoir refill, component replacement, and / or the start of a new production operation.
[0025] Optionally or additionally, event data may be warning messages or error messages from components of the production machine and / or user input at the production machine.
[0026] Generally speaking, it can be envisioned that the control unit extracts at least a portion of the event data from the sensor data provided to the control unit.
[0027] In one embodiment of the invention, the cause may be one of the following: idle time, exceeding the production plan, equipment defect, process defect in the production site, maintenance or cleaning of the production machine, production machine setup, or unknown cause. It has been proven that the aforementioned causes (excluding, of course, "unknown causes") are typical reasons for production machine downtime. Therefore, by training a machine learning module targeting these characteristics, production machine downtime can be tracked effectively.
[0028] In addition, the machine learning module provides identifiers for the production machine components that cause downtime. Therefore, any downtime can be accurately analyzed, and if, where appropriate, the control unit can recommend replacing a specific component if the production machine stops due to the accumulation of downtime caused by that component.
[0029] Feature data may include at least one of the following values: time since the last production period of the production machine, time since the last downtime period of the production machine, and / or the productivity of the production machine in its respective period. By using these parameters, the machine learning module achieves a good trade-off between fast and accurate evaluation in practice.
[0030] In one implementation, the combined data for subsequent time periods includes temporal overlap. For reliable data to be valid, the time periods need to be of a certain length. Therefore, this technique allows for more observations to be made.
[0031] This technique is also known as scrolling window or sliding window technique.
[0032] To provide convenient and easily understandable analysis of the machine learning module's output, the control unit stores the downtime periods and their temporal representations. A display can be assigned to the control unit, allowing it to display a visual assessment of the downtime periods.
[0033] In one implementation, the control unit may additionally provide the expected duration of the downtime. This makes it possible to respond quickly to longer downtimes, such as promptly outsourcing production to other machines.
[0034] For example, the control unit calculates the expected duration based on the duration of similar previous downtime.
[0035] It can be envisioned that the control unit determines the severity of the downtime based on the cause and components that led to the downtime.
[0036] In other words, the expected duration will be shorter if components can be replaced quickly.
[0037] Furthermore, the control unit can save the duration of all previous downtimes, search for downtimes with the most similar signatures, and calculate the expected duration of the current downtime based on the durations of previous downtimes.
[0038] According to another aspect of the invention, the control unit additionally performs the following steps to determine the settings of the production machine:
[0039] - Track the current job identifier of production being performed on the production machine, and
[0040] - Detect changes to the current job identifier, and
[0041] - If the length of the downtime period is within a certain time range, then the downtime period will be represented as the set time period.
[0042] In other words, the control unit executes the verification algorithm to increase the reliability of the machine learning module's results.
[0043] The object of this invention is further addressed by a system for tracking downtime of a production machine. This system includes a production machine and a control unit. The production machine processes products according to production target data and has at least one sensor that provides sensor data. The control unit continuously receives sensor data from the production machine and is adapted to execute the method described above. Regarding the features and advantages of the system, the advantages and features of the method also apply to the system.
[0044] The production machine can be one of a printing press, die-cutting machine, hot foil stamping machine, folding adhesive machine, or lithographic laminator. Therefore, the above method can be used on a variety of production machines, thus possessing versatility.
[0045] It is conceivable that the system includes at least one additional production machine that processes products based on production target data. This additional production machine has at least one sensor that provides sensor data, and the control unit continuously receives sensor data from the additional production machine and characterizes the downtime periods of all production machines. Therefore, the downtime of the entire production plant can be recorded, and in this way, the overall productivity of the plant is improved. Attached Figure Description
[0046] With the aid of the accompanying drawings, further features and advantages of the invention will become apparent from the description of the following two embodiments, wherein:
[0047] - Figure 1 This is a schematic block diagram of a system according to a first embodiment of the present invention.
[0048] - Figure 2 For use Figure 1 A schematic block diagram of the system executing the method according to the present invention.
[0049] - Figure 3 for Figure 2 A schematic diagram illustrating the calculation of feature data within a time period in one step of the method.
[0050] - Figure 4 For the reason Figure 2 The method uses a machine learning module that provides a diagram of possible output values.
[0051] - Figure 5 for Figure 1 Possible graphical representations of the system's tracked downtime analysis, and
[0052] - Figure 6 This is a schematic block diagram of a system according to a second embodiment of the present invention. Detailed Implementation
[0053] Figure 1The system 10 shown includes two production machines 12 and a central unit 14.
[0054] Each production machine 12 has multiple components 16 and multiple sensors 18, and is adapted to process products 20 according to production target data PTD provided by the central unit 14.
[0055] To be precise, each production machine 12 uses its component 16 to process product 20.
[0056] Sensors 18 monitor the current status of their respective production machines 12 and provide corresponding sensor data SD. The sensor data is continuously fed to the central unit 14 via data lines or wireless communication.
[0057] For example, sensor data SD can be transmitted to the central unit 14 via WLAN or Bluetooth connection.
[0058] In the illustrated embodiment, the production machine 12 is a flexographic printing press 22, and the product 20 is a sheet of paper 24.
[0059] The components 16 of the printing press 12 are an ink tray 26, an anilox roller 28, and a printing roller 30.
[0060] Anilox roller 28 removes ink from ink tray 26 via rotational motion in a known manner and transfers the ink to printing roller 30. Printing roller 30 then transfers the ink onto sheet 24.
[0061] Therefore, in the embodiment, the processing of product 20 does not show the printing of the form on sheet 24.
[0062] It must be understood that, Figure 1 Essentially illustrative, the components are typically more numerous than the shown component 16; that is, the printing press 22 typically has multiple ink trays 26, anilox rollers 28, and printing rollers 30.
[0063] Generally speaking, production machine 12 can also be a die-cutting machine, hot foil stamping machine, folding adhesive machine or flatbed laminator.
[0064] exist Figure 1 In this implementation, the two production machines 12 are of the same type, that is, these production machines are both printing machines 22.
[0065] However, the production machine 12 can also be of different types. For example, the first production machine 12 can be a printing press 22, and the second printing production machine 12 can be a folding adhesive machine that further processes the product 20 processed in the first production machine 12.
[0066] Furthermore, system 10 may include multiple production machines 12.
[0067] To improve the productivity of system 10, system 10 is adapted to track the downtime of production machine 12. For this purpose, central unit 14 has control unit 32.
[0068] More specifically, the control unit 32 includes a data medium 34 and a computing unit 36, wherein the data medium 34 has a computer program stored therein that can be executed on the computing unit 36 and includes program code, and is intended to track downtime of the production machine 12.
[0069] For this purpose, the control unit 32 uses Figure 2 The method is shown in the block diagram. In the block diagram, solid boxes represent logic blocks of control unit 32, and dashed boxes represent hardware components, i.e., physical components of system 10. Furthermore, arrows indicate data flow between software and / or hardware components of system 10. For simplicity,
[0070] In the first step, the control unit 32 continuously receives sensor data SD from the sensor 18, and also receives production target data PTD. This data is continuously stored in the volatile or non-volatile memory of the control unit 32.
[0071] Subsequently, the preprocessing module 38 combines the sensor data SD and the production target data PTD from a certain time period 40. Figure 3 ).
[0072] In the illustrated embodiment, each time period 40 is 10 minutes long, and subsequent time periods 40 overlap in a 5-minute window, i.e., the last 50% of the previous time period.
[0073] It must be understood that the length of time segment 40 and the length of overlapping time segments are illustrative in nature. Therefore, the total length of time segment 40 can also be shorter or longer (e.g., 5 minutes or 15 minutes), and the length of overlapping time segments can also be shorter or longer (e.g., the last 25% or 75% of the previous time segment).
[0074] Preprocessing module 38 additionally calculates feature data CD for each time period 40. Figure 2 ).
[0075] For example, the preprocessing module 38 calculates the time since the last production period of the production machine 12, the time since the last downtime period of the production machine 12, and / or the productivity of the production machine 12 during that period 40.
[0076] The productivity of production machine 12 can be set as a percentage of the maximum possible productivity of the production machine.
[0077] In other words, if production machine 12 processes product 20 at full speed for 8 minutes out of 10 minutes and is idle for the other 2 minutes, the preprocessing module 38 will calculate a productivity value of 80%.
[0078] In addition, the preprocessing module 38 determines the specific event E from the sensor data and provides the corresponding event data ED.
[0079] In the next step, the preprocessing module 38 feeds the feature data CD and event data ED to the classification module 42.
[0080] The classification module 42 determines whether the production machine 12 is processing product 20 in the corresponding time period 40 based on the feature data CD and the event data ED.
[0081] In other words, the classification module 42 divides the corresponding time period 40 into downtime period 44 or production period 46. Figure 4 ).
[0082] For example, if the productivity of the corresponding time period 40 is less than 50%, or if the production machine 12 does not process any product 20 for more than 3 minutes, the classification module 42 will classify the time period 40 as a downtime period 44.
[0083] If the classification module 42 detects the existence of the downtime period 44, the feature data CD and event data ED will be fed to the machine learning module 48 of the control unit 32.
[0084] The machine learning module 48 includes at least one neural network that is trained to provide the cause R and identifier ID as output values based on the data provided as input values.
[0085] In other words, the machine learning module 48 provides the cause R40 of the downtime of the production machine during downtime period 44, and the identifier ID of the component 16 that caused the downtime of the production machine 12. Figure 4 ).
[0086] Specifically, Machine Learning Module 48 provides one of the following reasons in R. Additionally, examples are given for each reason.
[0087] - Idle time (the planned period during which production machine 12 should not process any products),
[0088] - Production exceeded the plan (production machine 12 was unable to process any products during downtime 44, for example, because production machine 12 could not obtain the corresponding product 20).
[0089] - Equipment defect (component 16 of production machine 12 is faulty or mis-indicating, therefore processing of product 20 must be stopped during downtime period 44),
[0090] - Process defects in the production area (paper jam detected, the operator of the production machine must resolve the paper jam),
[0091] - Maintenance / Cleaning (The printed form on paper 24 is found to be of poor quality, therefore the printing roller 30 removed from printing press 22 must be cleaned).
[0092] -Settings (To start a new printing job, new ink must be filled into ink tray 26), and
[0093] -Unknown (all other downtime periods 44).
[0094] If the downtime period 44 is caused by a specific component 16 of the production machine 12, the machine learning module 48 also provides a corresponding identifier for that component 16; in all other cases, the machine learning module provides an unknown label.
[0095] The identifier ID and cause R of component 16 that caused the downtime are then fed into the analysis module 50 of control unit 14.
[0096] Analysis module 50 stores the identifier ID and cause R, and calculates the duration of the specific downtime in time resolution in data medium 34.
[0097] Accordingly, the analysis module 50 establishes a database of the downtime and duration of the production machine 12 so that the analysis module can provide the expected length of the current downtime.
[0098] For example, the analysis module 50 searches the database for entries with the same cause R and the same component identifier 16, and provides the average of all found entries as the expected duration of the downtime.
[0099] In addition, the analysis module 50 is also suitable for providing verification of cause R in the case of ma.
[0100] Therefore, the analysis module 50 performs the following steps:
[0101] - Track the current job identifier of production being performed on production machine 12.
[0102] - Detect changes to the current job identifier, and
[0103] - If the length of time period 44 is within a certain time range, provide the reason R "Setting" for the downtime period 44.
[0104] In other words, the threshold for this length is stored in data medium 34, and the analysis module verifies the cause R of the machine learning module.
[0105] If the machine learning module 48 and the analysis module 50 provide different reasons for a certain downtime period 44, the reason for that downtime period will be changed to "unknown".
[0106] Similarly, it can be envisioned that the analysis module 50 performs the above steps on all the outputs of the machine learning module 50.
[0107] Subsequently, the control unit 32 displays graphical analyses 54 and 56 of the tracked downtime on the control unit's display 52. Figure 5 ).
[0108] The first analysis 54 provides time profiles for the period 58 in which no production was planned and the period 60 in which production was planned. These periods 58 and 60 are taken from the production target data PTD.
[0109] For each time period 60 in which production is planned, the duration of the actual production time period 46 and the duration of the downtime period 44 of the production machine are shown.
[0110] In the second analysis 56, the total number of occurrences of the causes of downtime and the total duration of downtime corresponding to each cause R are shown in the form of a pie chart.
[0111] This provides a simple analysis and tracking of the downtime of production machine 12. In particular, the machine operator can easily see the cause R of the time aspect that leads to the downtime of production machine 12.
[0112] Generally speaking, it can be envisioned that if the operator of production machine 12 selects a specific reason R, for example by clicking on a specific reason R, detailed information about the downtime period for that specific reason can be provided on display 52.
[0113] exist Figure 6 In the second embodiment of system 10, with Figure 1 A similar block diagram is shown. Figure 6 System 10 essentially corresponds to Figure 1 Since this is system 10, the differences between the first and second embodiments will only be discussed below. Identical and functionally identical components are provided with the same reference numerals.
[0114] and Figure 1 Compared to system 10, control unit 32 is not integrated into the central unit, but rather into production machine 12.
[0115] Accordingly, each production machine 12 in the production plant can be equipped with its own control unit 32.
[0116] However, it is conceivable that all control units 32 are interconnected and / or provide their data to the central unit.
[0117] In addition, downtime data from different production plants can be shared between them by uploading their respective data to a central server and downloading it.
[0118] Regarding idle time, there are currently three steps. First, the activity of the equipment over a period of at least two months is analyzed to automatically detect recurring interruptions in production. Then, a signature is created for each piece of equipment where a recurring interruption is detected. Finally, each time downtime occurs, it is matched against these signatures to see if it corresponds to the "idle time" category.
[0119] Steps 1 and 2 are performed offline, requiring at least one month, preferably two months, of production time on the new equipment before applying steps 1 and 2, and then re-running them every few months on the older equipment to obtain more up-to-date data. Here, "offline" refers to running the algorithm using all available data from the beginning as a non-rotating activity.
[0120] Step 3 is performed online and in real-time using the same pipeline as the setup detection. "Online" here refers to an algorithm that processes the data gradually as it arrives in the cloud in real time.
[0121] Step 1
[0122] The goal of step 1 is to mark the time intervals at which regular production interruptions occur throughout the week.
[0123] The data used in this step comes from telemetry data in our cold storage. However, the same result can also be obtained by slightly adjusting the machine events from both cold and hot storage.
[0124] Apply the following operations to the data in sequence:
[0125] 1) Search availability:
[0126] a) Filter outlier data (e.g., missing data).
[0127] b) Resample the data so that there is one point every 5 minutes.
[0128] c) Switching data from absolute to relative
[0129] d) Crop data between 0 and 1
[0130] 2) Use available, clean data:
[0131] a) Calculate median availability
[0132] b) Use median availability to determine downtime intervals
[0133] c) Filter out long downtime (over 1 hour).
[0134] d) Filter out short downtime (5 minutes or less).
[0135] 3) Calculate daily availability:
[0136] a) Clean data filtered by minute and hour
[0137] 4) Identify frequent interruptions
[0138] a) Calculate median daily availability
[0139] b) Use half of the median availability to locate idle periods.
[0140] c) Filter out long idle times (more than 1 hour).
[0141] d) Filter out short idle times (5 minutes or less).
[0142] Step 2
[0143] The goal of Step 2 is to create a signature for each valid free time period found in Part 1. The signature consists of variables such as:
[0144] - Average duration of the interruption
[0145] -Variability of duration between events
[0146] - The variability of the time at which interruptions occur between events
[0147] The data used in this step is the output of step 1, as well as the input data of step 1.
[0148] The following operations will be applied to our data in sequence:
[0149] 1) Extract downtime intervals from telemetry data
[0150] a) Use machine status data to find downtime intervals
[0151] b) Filter out long downtime (over 1 hour).
[0152] c) Filter out short downtime (5 minutes or less).
[0153] 2) Create statistics for each idle time period identified in step 2.
[0154] a) Select all downtimes that intersect with the idle period.
[0155] b) Calculate the 0.85-HDR (highest density region) of the idle time density function.
[0156] c) Extract the variability of interrupt occurrence time from the HDI above.
[0157] d) Calculate the mean and standard deviation of the duration from the selected downtime.
[0158] Step 3
[0159] The goal of step 3 is to use the signature created in step 2 to classify downtime as idle time. This step is straightforward: when a microservice is asked to classify downtime, the downtime undergoes the same series of checks as before, and if a signature exists for the corresponding device, the new algorithm pipeline runs in parallel with other algorithms (such as setup).
[0160] In the algorithmic pipeline targeting idle time, the middle segment of the downtime is matched against the signature. If a match is found (at most one can be constructed), the duration is compared with the signature. It needs to be within one standard deviation of the pipeline's average duration to return a positive match.
[0161] If the idle time algorithm pipeline matches, the microservice returns the same downtime, but the predicted category is "idle time". Only matches from the configured pipeline will win.
Claims
1. A method for tracking downtime of a production machine (12), the method comprising the steps of: a) The control unit (32) continuously receives sensor data (SD) and production target data (PTD) from the production machine (12). b) Combine sensor data (SD) and production target data (PTD) within a certain time period (40) to provide combined data (D), and the control unit (32) calculates the feature data (CD) of the combined data (D). c) Determine whether the combined data (D) originates from the downtime period (44) of the production machine (12) based on the feature data (CD), and d) The downtime period (44) is characterized using a machine learning module (48) implemented in the control unit (32), wherein the machine learning module (48) provides one of a set of predefined causes based on input values, wherein the predefined causes are taught to the machine learning module (48) through training, the machine learning module (48) receives feature data (CD) of the downtime period (44) as input values and provides the cause (R) of the downtime period (44) as output values; The control unit (32) stores the downtime period (44) and its time resolution representation, and The method is characterized in that, in the case that the downtime period (44) is caused by a specific component (16) of the production machine (12), the machine learning module (48) additionally provides the corresponding identifier (ID) of the component (16) of the production machine (12) that caused the downtime of the production machine (12).
2. The method according to claim 1, wherein the control unit (32) considers only these time periods as downtime periods (44) in which production of the production machine (12) has stopped for at least one minute.
3. The method according to claim 1, wherein the control unit (32) considers only these time periods as downtime periods (44) in which production of the production machine (12) has stopped for at least three minutes.
4. The method according to any one of claims 1 to 3, wherein the control unit (32) additionally receives event data (ED) from the production machine (12) and additionally provides the event data (ED) to the machine learning module (48) as input values.
5. The method according to any one of claims 1 to 3, wherein the cause (R) is one of idle time, exceeding the production plan, equipment defect, process defect in the production site, maintenance or cleaning of the production machine (12), setup of the production machine (12), or unknown cause.
6. The method according to any one of claims 1 to 3, wherein the feature data (CD) includes at least one of the following values: time since the last production of the production machine (12), time since the last downtime period (44) of the production machine (12), and / or the productivity of the production machine (12) in the respective time period (40).
7. The method according to any one of claims 1 to 3, wherein the combined data (D) of the subsequent time period (40) includes time overlap.
8. The method according to any one of claims 1 to 3, wherein the control unit (32) stores the downtime period (44) and its time resolution representation, wherein a display (52) is assigned to the control unit (32), wherein the control unit (32) displays a visual assessment of the downtime period (44) on the display (52).
9. The method according to any one of claims 1 to 3, wherein the control unit (32) additionally provides the expected duration of downtime of the production machine (12).
10. The method according to any one of claims 1 to 3, wherein the control unit (32) additionally performs the following steps to determine the setup of the production machine (12): a) Track the current job identifier of production being performed on the production machine (12), b) Detect changes to the current job identifier, and c) If the length of the downtime period (44) is within a certain time range, then the downtime period (44) is characterized as the set time period.
11. A system for tracking downtime of a production machine (12), the system comprising: Production machine (12) that processes products (20) according to production target data (PTD), said production machine (12) having at least one sensor (18) that provides sensor data (SD), and A control unit (32) continuously receives sensor data (SD) from the production machine (12), the control unit (32) being configured to perform the method according to any one of the preceding claims.
12. The system according to claim 11, wherein the production machine (12) is one of a printing press (22), a die-cutting machine, a hot foil stamping machine, a folding adhesive machine, or a lithographic laminator.
13. The system according to claim 11 or 12, the system comprising at least one additional production machine (12) processing products according to production target data (PTD), the additional production machine (12) having at least one sensor (18) providing sensor data (SD). in, The control unit (32) continuously receives sensor data (SD) from the additional production machines (12) and characterizes the downtime of all production machines (12).