EP4172919A1

EP4172919A1 - Error message analysis in a production line

Info

Publication number: EP4172919A1
Application number: EP21730954.1A
Authority: EP
Inventors: Alexandru MARCU; Vincent FRENTZEL
Original assignee: JT International SA
Current assignee: JT International SA
Priority date: 2020-06-30
Filing date: 2021-06-09
Publication date: 2023-05-03
Also published as: JP2023530572A; WO2022002550A1

Abstract

There is disclosed a method, error analysis device and system for reporting and analysing error messages in a manufacturing production line. Specifically the invention comprises carrying out the steps of receiving a plurality of error message, from one or more machines in the production line, each error message relating to an error that has been detected at its associated machine, each error message comprising one or more error codes specific to its associated machine indicating the type of error; processing the plurality of error messages, and generating and displaying a report of the processed error messages, such that a user can take action regarding the errors. The processing further comprises assigning a descriptor to each error message through translating the one or more error codes of the error message into a readable format; determining a stage in the production line to which each of the plurality of error messages relate; grouping the plurality of error messages relating to the same stage in the production line; organising the groups of error messages such that they are arranged sequentially to identify a primary cause of the plurality of error messages.

Description

ERROR MESSAGE ANALYSIS IN A PRODUCTION LINE

FIELD

The present invention relates to the field of error messages in manufacturing production lines. Specifically error messages relating to machine downtime in such production lines.

BACKGROUND

Machine stoppages, commonly known as downtimes, are an issue in manufacturing production lines resulting in reduced output for the factory as fewer products are produced. Due to the nature of production lines, with numerous machines each carrying out many different tasks, it is often difficult to quickly determine the root cause of these production downtimes. For a production line producing cigarettes, for example, the production line may consist of a series of machines for making the cigarettes, a series of machines for packaging the cigarettes into boxes, a series of machines for applying a tax stamp to the boxes, a series of machines parcelling a number of cigarette boxes together, and a series of machines for wrapping the parcelled cigarette packages. An error in a single machine in the line can cause a cascade of error messages being produced as the initial error has a knock on effect on subsequent processes in the line. These error messages may appear at such a speed that it may not be clear what the root cause is, and which of the messages are linked to one another, making it difficult to determine what action to take to remedy the errors. This can lead to there being an unnecessarily long downtime whilst the cause is trying to be determined and the line re-started. This is not helped by the fact that the error messages are machine specific and not easily readable by the workers on the production line who are often responsible for determining the problem and restarting the line. This is often a trial and error process for the worker, and part of their success may be based on their past experience of the same error having previously occurred. A worker may identify the specific remedy to a particular error message, but typically this information is not captured and shared to other workers so that they also know what action to take when faced with the same error.

In addition, across different production lines there may be different machines or different models of machines each having their own associated error messages. This means that insight for solving a particular error message on one line will not be transferable to solve errors on different lines. This means that separate approaches have to be taken for each line.

A unified approach is needed for tacking error messages on production lines to eliminate the amount of time the lines are out of action, and so that the insight obtained at a single line can be applicable across multiple different production lines with different machines and/or machine models.

SUMMARY

According to a first aspect there is provided a method, performed by an error analysis device, of reporting and analysing error messages in a manufacturing production line, the method comprising: receiving a plurality of error message, from one or more machines in the production line, each error message relating to an error that has been detected at its associated machine, each error message comprising one or more error codes specific to its associated machine indicating the type of error; processing the plurality of error messages, the processing comprising: assigning a descriptor to each error message through translating the one or more error codes of the error message into a readable format; determining a stage in the production line to which each of the plurality of error messages relate; grouping the plurality of error messages relating to the same stage in the production line; organising the groups of error messages such that they are arranged sequentially to identify a primary cause of the plurality of error messages; generating and displaying a report of the processed error messages, such that a user can take action regarding the errors. In this way, error messages may be translated into a human readable format such that they can be easily be understood by a user. In addition, through grouping messages relating to the same stage in the production line and arranging them sequentially in the order in time at which they have occurred it may be possible to determine which error message is the primary cause of the sequence of error messages. When presented as a report it can clearly be seen what the error messages relate to through the descriptor of each of the error messages, and through arranging the error messages in time order based on when they were created it can be seen which of the error messages is the primary cause of the subsequent error messages.

The error messages may be indicative of a machine downtime. It may be assumed that the primary cause of the error messages is the primary cause of the downtime, and that the earliest occurring error message is this primary cause. Through understanding the primary cause of the error message it may be possible to determine what actions are required to address the downtime, in order to get the production line running as quickly as possible.

The stages of the production line may be specific steps in the production of the product. For instance, stages may include: the making of the product, the packaging of the product, and the parcelling ready for shipment. This may be determined based on an indicator within the error message indicating the stage that the error message relates. Alternatively, or in addition, it may be based on the knowledge of the machine from which the error message has been received and knowing to which stage in the production line that machine relates.

The action that the user may take using the report may be to rectify the error to restart the line. For instance, this may be in real time, i.e. before the line has been restarted following receipt of the error messages.

Alternatively, the user action may be an action taken to rectify an error when the same error message is received again. This may be at a later point in time. For instance, generating the report may be to create a list of actions that a user should take when the error is seen again. This may form an action plan of suggestive corrective actions in the case that the same error occurs again.

Preferably, each error message comprises a time stamp. The time stamp may indicate the time at which the error message was triggered. In addition, the timestamp may also indicate a time when the error has been rectified. The sequential arrangement of the messages may be based on the timestamp. In other arrangements the sequential arrangement of the messages may be based on the order in which the messages have been received at the error analysis device.

The method may further comprise before generating the report: displaying the processed plurality of error messages to a user; and receiving user input directed to the displayed processed plurality of error messages allowing the user to modify the processed plurality of error messages. The user, such as a worker on the production line, may annotate the processed error messages with metadata. This may involve them adding further detail to indicate the cause of the error and/or to further categorise the error.

In some instances, the user may be responsible for resolving the error, such as restarting the machines on the production line in the situation where the error messages relate to a downtime. The user is able to modify the processed error messages to add specific details to each processed error message. For instance, they may add comments to the error messages indicating the nature of the error, such as its cause. They may also add information indicating what actions they have taken to rectify the error. This may include what actions they have taken to restart the production line. This may include details of successful actions and/or unsuccessful actions.

In some instances, the processed plurality of error message may be displayed to the user if a duration of the sequentially arranged error messages is above a threshold time period. The threshold may be a predetermined threshold. In this way, only downtimes that occur for a certain time period are displayed for the user for annotation. Short downtimes may be of less interest as they have been rectified quickly, whereas for long downtimes it may be insightful to determine what actions the user has taken and which have/have not worked. The processing of the error messages ensures that the sequentially arranged error messages relate to a single downtime. The duration may be the time from the start of the first error message to the time that the last error message is rectified relating to that primary cause.

The duration may be the duration of only a single group of error messages. For instance, the group relating to the packer only. Alternatively, the duration may be the duration of each of the sequentially arranged groups. For instance, a downtime in one stage may have had a knock on effect causing a downtime in a different stage. For instance, a downtime in the packer may have had a knock on effect at the parceller causing error messages to be generated.

Preferably, the threshold is above 15 minutes. In other arrangements, the threshold is preferably above 2 hours. In other arrangements the threshold may be a time period that is suitable for the particular production line.

Alternatively, or in addition, the processed plurality of error messages may be displayed to the user if the primary cause of the error messages relate to manual intervention that has caused generation of said error message. This enables the user to modify the processed error messages so as to indicate why they may have caused the downtime of the line.

Preferably, the step of processing further comprises assigning a descriptor to each of the plurality of error messages indicating a type of problem that has caused generation of the error message. By having a descriptor indicating the type of problem it can easily be seen what type of problem each error message relates to. The type of problem that has caused the error message may be determined. In some arrangements this may be determined through having a database of error messages and problem types. In this way, the problem type may be determined automatically. Alternatively, or in addition, the problem type may be input by the user through user input. The problem type may be the problem that has directly caused the generation of the error message. For instance, the problem may be that the machine may have run out of input material and the error message is generated to indicate this problem. This problem may have been caused by the primary cause, which may be at a stage or process at an earlier point in the production line.

The step of processing may further comprise classifying whether or not each of the plurality of error messages relates to a manual intervention that has caused generation of the error message. In this way, it can be determined which error messages are a result of the machines in the assembly line not functioning correctly, or if a worker has caused the error message generation. This may be useful in aiding identification of error messages that are caused by an intentional user action, such as shutting down the assembly line for maintenance and/or cleaning. This may be determined through pre-set times specifically being known to be when the line is in downtime. Alternatively, it may be through the user input modifying the classification of whether the plurality of error messages relate to manual intervention.

In some instances, when it is determined that the error messages relate to manual intervention they may be ignored. For instance, they may be deleted and not used in the report. Alternatively, they may be marked clearly so that they are distinguishable from other types of the error messages in the report. In some instances, the user input may comprise modifying the classification of whether or not the plurality of error messages relates to manual intervention.

Preferably, each stage in the production line comprise a series of processes, and wherein the step of processing the plurality of error messages further comprises determining the process to which each of the plurality of error messages relate.

Each stage in the production line is comprised of a series of processes that carry out specific parts of the function of the stage. By determining the specific process to which each error message relates it can aid in determining further details of the nature of the error. It can further aid analysis at a later point in time such that the report may be used to pinpoint which processes are causing the most errors and also indicating the nature of errors to which each process are susceptible.

In some arrangements the process may be determined through having a database of error messages and how they relate to specific processes. Alternatively, or in addition, the process may be determined based on the specific machine from which the error message has been received. For instance, it may be known which machine relates to which process. In this way, the process may be determined automatically. Alternatively, or in addition, the process may be input by the user through user input.

The step of determining a stage may further comprise, for each error message of the plurality of error messages: identifying if the error message is triggered indirectly by an error caused by a different stage to which the error message is associated; and if the error message is triggered by an error caused by a different stage to which the error message is associated assigning the error message to a group relating to that stage. Advantageously, this allows the re classification and assigning of error messages. This may be done by the error analysis device or be done through user input. For instance, it may involve assigning the error message to a different process or stage.

Preferably, for at least one error message of the plurality of error messages the method further comprises identifying a component of the error message’s associated machine that the error message relates, and assigning a descriptor to the error message indicating the component of the machine. By identifying which specific component of the machine to which the error message relates the cause of the error message can be further pinpointed. This may be done for each of the error messages. For instance, when the primary cause is identified, by knowing the specific component of the machine assembly to which the error message relates this can provide a guide as to where the attention needs to be to address the error. This can decrease the amount of time taken to rectify errors. When the errors relate to downtime this can reduce the amount of time the line is out of action, and thus help to increase the output of the line. This descriptor may be in a human readable format enabling it to be readily understood to users. In addition, analysis over time of this data can be used to show which components of the machines are responsible for the most errors. This can enable appropriate action to be taken to address these problems.

The processing step may further comprise identifying duplicate error messages in the plurality of error messages, and deleting the identified duplicate error messages. In this way, the number of messages can be reduced to focus only on unique messages. This reduces the number of messages that need to be processed thus reducing the computation resources required. The duplicate error messages may be identified through identical error message that has been generated multiple times. In other arrangements the duplicate error messages may be different error messages that are known to signal the same error.

Preferably, the step of assigning a standardised descriptor to each error message through translating the one or more error codes into a readable format comprises translating the error codes through using a reference source having details of the meaning of each error code for that machine. The reference source may include machine specific documentation which includes details of what each of the error codes mean for the specific machine. This can be used to convert the unique error codes into the human readable format. The reference source may be stored in a database. The data base may be a local database or a cloud database. This may be the same database where the processed error messages and reports are stored.

The report of the processed error messages may comprise details of which errors have been responsible for the most downtime of the manufacturing production line. The errors responsible for the most downtime may be the identified primary cause that has caused the largest number of errors. This may be indicated as the process that has led to this error. This may be displayed for each stage.

In some arrangements, the steps of the first aspect may be repeated numerous times in order to build up a collection of processed error messages relating to different problems. These collections of processed error messages may be output in the report. In this way, the report may show the most regularly occurring error messages/problems.

The report may further comprise details of actions that may be taken to resolve the error. This may be by collecting details of how errors are solved through the user input. In this way, the report may act as a resource aiding users to solve problems when they reoccur.

According to a further aspect there is provided a data analysis device for reporting and analysing error messages in a manufacturing production line, the data analysis device comprising: a receiving module, configured to receive a plurality of error message, from one or more machines in the production line, each error message relating to an error that has been detected at its associated machine, the error message comprising one or more error codes specific to its associated machine indicating the type of error; a processing module configured to process the plurality of error messages, the processing comprising: assigning a standardised descriptor to each error message through translating the one or more error codes of the error message into a readable format; determining a process stage in the production line to which each of the plurality of error messages relate; grouping the plurality of error messages relating to the same process stage in the production line; organising the groups of error messages such that they are arranged sequentially to identify a primary cause of the plurality of error messages; a display module configured to generate and display a report of the processed error messages, such that a user can take action regarding the errors.

According to a further aspect there is provided a computer program product comprising instructions which, when the program is executed by a computer, cause the computer to carry out the following steps: receiving a plurality of error message, from one or more machines in the production line, each error message relating to an error that has been detected at its associated machine, the error message comprising one or more error codes specific to its associated machine indicating the type of error; processing the plurality of error messages, the processing comprising: assigning a standardised descriptor to each error message through translating the one or more error codes of the error message into a readable format; determining a process stage in the production line to which each of the plurality of error messages relate; grouping the plurality of error messages relating to the same process stage in the production line; organising the groups of error messages such that they are arranged sequentially to identify a primary cause of the plurality of error messages; generating and displaying a report of the processed error messages, such that a user can take action regarding the errors.

According to a further aspect there is provided a system comprising: a manufacturing production line, the manufacturing production line comprising one or more machines for manufacturing a product; and a data analysis device for reporting and analysing error messages from the manufacturing production line, the data analysis device comprising: a receiving module, configured to receive a plurality of error message, from one or more machines in the production line, each error message relating to an error that has been detected at its associated machine, the error message comprising one or more error codes specific to its associated machine indicating the type of error; a processing module configured to process the plurality of error messages, the processing comprising: assigning a standardised descriptor to each error message through translating the one or more error codes of the error message into a readable format; determining a process stage in the production line to which each of the plurality of error messages relate; grouping the plurality of error messages relating to the same process stage in the production line; organising the groups of error messages such that they are arranged sequentially to identify a primary cause of the plurality of error messages; a display module configured to generate and display a report of the processed error messages, such that a user can take action regarding the errors.

Although it has been described above that the error messages relate to downtimes this is not necessarily the case. For instance, in other embodiments the line may not have stopped, and may continue despite error messages being triggered. In this instance, the error messages may indicate problems in the line that need to be fixed. In this way the line may still be operating but at a reduced rate. The above described methods may be used to rectify these errors.

DESCRIPTION OF DRAWINGS

Figure 1 shows a schematic view of an example production line on which the present invention may be applicable;

Figure 2 shows a flow chart of an example method of reporting and analysing error messages in a manufacturing production line as shown in Figure 1 ;

Figure 3 shows a table of raw error messages received from a production line;

Figure 4 shows a table of processed error message as processed according to an aspect of the present invention;

Figure 5 shows a user interface presented to the user allowing them to modify the error messages;

Figure 6 shows an example view of a series of tapes showing downtimes in the production line; Figure 7 shows a further example view of a series of tapes showing downtimes in the production line;

Figure 8 shows a table showing the different processes for each of the stages in an example cigarette production line;

Figure 9 shows an example user interface displaying an analytics report based on the processed error messages and tapes;

Figure 10 shows an example user interface showing a report which includes details of the most frequently recurring issues leading to the machine downtimes; Figure 11 shows an example user interface showing a report which provides details on the problems, the actions to solve them, and details on whether they have been solved;

Figure 12 shows a schematic view of an example system for performing the method shown in Figure 2; and

Figure 13 shows a schematic view of an example data processing device capable of performing the method shown in Figure 2.

DETAILED DESCRIPTION

The embodiments disclosed herein relate to methods, and devices, for identifying, processing and actioning on error messages in a production line. Specifically, manufacturing production lines. One of the aims of the present invention is to improve the productivity of these production lines through analysing error messages that are produced with the purpose of reducing the amount of time the production line is out of action. Figure 1 shows an example schematic view of a production line 10 according to the present invention. The production line involves a number of different stages 2a 2b 2c. At each stage 2a 2b 2c a different step in the manufacturing of the product is performed. In the examples described herein the product that is being produced is cigarettes. However, it would be understood that the invention described herein may not necessarily be limited to production lines for the production of cigarettes, and may be applicable to any type of production line.

As can be seen from Figure 1 the first stage 2a, stage 1, is the maker. This is the stage where the cigarette is formed. The second stage 2a, stage 2, is the packer stage. This is where the cigarettes that have been made in the first stage 2a are packaged together, such as into boxes. The third stage 2c, stage 3, is the stage where the packaged cigarettes are wrapped, such as in plastic wrapping to avoid tampering, so called the wrapper stage. In some production lines a single machine may perform the functions of each stages 2a 2b 2c. For instance, there is a single machine performing the maker stage, a single different machine performing the packer stage, and a single different machine performing the wrapper stage. However, in other production lines multiple different machines may be responsible for performing the functions of each of the stages 2a 2b 2c, or the same machine may be responsible for performing all of the sates 2a, 2b 2c.

As can be seen from Figure 1 , each of the stages 2a 2b 2c are each made up of a plurality of different processes. Stage 2a is made up of process 4a and process 4b. Typical processes that the maker may perform may include feeding the cigarette paper into the machine, applying the filter to the cigarette, or cutting the cigarettes that are formed.

Stage 2b is made up of process 4c and process 4d. Typical processes that the packer may perform include feeding the foil wrapper into the machine, bending the blank box to shape, or gluing the blank to form the box.

Stage 2c is made up of process 4e and process 4f. Typical processes that the wrapper may perform may include feeding the pack into the machine, applying the film to the pack, or sealing the pack.

These stages and processes are only representative of an example production line and other stages and processes may be present other than those as shown. Additional stages and processes may be located in-between, or before or after, the stages and processes shown in Figure 1. Figure 8 provides further details on this, with table 800 showing example stages 801 and associated processes 803 in an example cigarette production line. The steps of the production line shown in Figure 1 flow from left to right as viewed in the figure, such that a product is subject to each of the processes 4a and 4b in stage 2a, then subject to each of the processes 4c and 4d in stage 2b, and then subject to each of the processes 4e and 4f in stage 2c. As each process may rely on the output of the previous process, a problem in a single one of the processes in the line can lead to a knock on effect of other issues occurring at the other processes in the line. A problem at one process may cause issues at processes further down the line, but also processes up the line. This may result in many different error messages being displayed as each process is affected. This may be confusing for the worker on the production line as the large number of error messages may not enable them to quickly pinpoint the source of the error. In addition, when reviewing the downtime of the lines at a later point in time, such as for performance analysis, it may not be clear through looking at the large number of error messages what has caused the issue. One aim of the present invention is to solve these problems.

Figure 2 shows an example method 200 of reporting and analysing error messages in a manufacturing production line. The method starts at step 201 which involves receiving a plurality of error message, from one or more machines in the production line, each error message relating to an error that has been detected at its associated machine, the error message comprising one or more error codes specific to its associated machine indicating the type of error.

The error messages are then processed in steps 203 to 209. Step 203 involves assigning a descriptor to each error message through translating the one or more error codes of the error message into a readable format. At step 205 a stage in the production line to which each of the plurality of error messages relate is determined.

Next, step 207 involves grouping the plurality of error messages relating to the same stage in the production line.

At step 209 the groups of error messages are organised such that they are arranged sequentially to identify a primary cause of the plurality of error messages.

Finally, at step 211 a report of the processed error messages, is generated and displayed, such that a user can take action regarding the errors. Figure 12 shows a schematic of the system 1200 in which the method 200 of Figure 2 may be implemented. The system includes error analysis device 1201 , production line 1213, and database 1211.

Production line 1213 may be the production line 10 as shown in Figure 1. Database 1211 may be an external database as shown. For instance, it may be a cloud database or a local database, or data warehouse. Alternatively, the database 1211 may be part of the error analysis device 1201.

Error analysis device 1201 includes receiving module 1203, processing module 1205, and display module 1207. Receiving module 1203 is responsible for receiving the error messages from the production line 1213 as described in step 201 of Figure 2. It may also be responsible for receiving the data stored in database 1211 , and/or receiving user input from workers on the production line.

Processing module 1205 is responsible for processing the error messages from the production line as described above, and for performing steps 203 to 209 as shown in Figure 2.

Display module 1205 is responsible for displaying the processed error messages from the production line as described above, and for performing step 209 as shown in Figure 2. The display module 1205 may actually aid in the displaying of the processed error messages, or may be responsible for transmitting the processed error messages and reports to be displayed elsewhere.

Further details on the processes performed by the error analysis device, and the method shown in Figure 2, will be described in further detail below.

As outlined in relation to Figure 1 , when there is an error in the production line error messages may be triggered. Typically these may be displayed on the user interfaces on the machines in the production line so that the workers can see the errors, such as human machine interface (HMI) of a programmable logic controller (PLC). Alternatively, a worker on the production line may have a handheld computer, such as a mobile data computer (MDC), on which they can view the error messages that have been triggered. As outlined above, a large number of these raw error messages may be triggered making it difficult for the user to determine what actions should be taken to solve the issues in the production line.

Figure 3 shows a table 300 which includes a plurality of error messages 315a-g, with each error message 315a-g occupying a different row in the table 300. The error messages 315a-g shown in Figure 3 are the raw error messages received from the machines in the production line, which may traditionally be shown to the user on a user interface associated with the machine or the user’s associated handheld terminal.

Each error message 315a-g includes details of the plant in which the error message has come from 301 and the workcenter 303. These indicate from which production line the error messages have originated. A machine ID 305 is also indicated and the source machine 307. In this instance the source machine 307 indicates that the messages in table 301 are from the Maker, e.g. stage 2a in Figure 1. A reason code 309 for the error is also provided in each error message. The reason code 309 is a series of numerical digits which represent the type of error that has occurred. A breakdown start date 311 and breakdown end date 313 are also shown in each of the error messages. These indicate the period over which the error has occurred which have caused the generation of the error message.

As can be seen from table 300 the raw error messages 315a-g are difficult to interpret in their current form. For instance, without being deeply familiar with what each error code 309 means a worker on the production line would have no way of knowing to what the error message relates. With such a wide number of error messages 315a-g being produced from a large number of different machines in the production line it would be difficult for a worker on the production line to be familiar with the meaning of each and every error message 315a-g. In addition, these error messages 315a-g in the form shown in table 300 would be even less insightful for a user, who is not working directly on the line, looking at the error messages 315a-g with the purpose of analysing the error message to determine the cause of downtimes in the lines. To alleviate these issues the error messages are processed to provide a more enriched form of data. Figure 4 shows a table 400 of error messages 415a-c which have been processed.

Each processed error message 415a-c includes a start time 401 and an end time 403 indicating when the error commenced and when it was rectified. This is based on the data from the raw error messages in columns 311 and 313 in Figure 3.

Column 405 incudes a description 405 “MDC Message English” that describes in the local language the cause of the error. In this case the description is in English, however this may be any language which may depend where the machine is operating.

Each message has also been classified into whether it is a direct or indirect error, as shown in column 407. A direct error is one which is the primary cause of the problem. An indirect error is one which is caused indirectly by a previously occurring direct error. For instance, as can be seen in Figure 4 the message in row 415c is an indirect error that has been caused by the direct error in row

415b. The error in row 415b, relating to a rear paper break in the printer of the cigarette paper/transport process, is the first error relating to this problem. The error in row 415c is identical to the error in row 415b, but at a later point in time. This may be due to the line being restarted after the error 415b without the cause of the initial error being fixed, thus resulting in the same error occurring again as indicated by error 415c.

Column 409 includes a reason for each error. This has been determined through translating the error codes in column 309 into the descriptor shown in column 409. For instance rather than a reason code such as 1.1.1103 as shown in column 309, when processed in this way, each error has a user understandable meaning such as “INTERNAL MACHINE STOP” as shown in column 409.

Each error message is also assigned to a process stage in the production line as shown in column 411. This may be, for instance, process 4a or 4b as shown in Figure 1. In the case shown in Figure 4 the process stage of each error message is “CIGARETTE PAPER/ TRANSPORT”.

A problem type is also assigned to each error message as shown in column 413. This may be a specific problem that has caused the error message to be generated. For instance, in the examples shown in Figure 4 the problem type for the error in row 415a is “MACHINE/ REJECT LIMIT”, and the problem type for the error in rows 415b and 415c are “MATERIAL/BREAK”.

The part of the machine where this problem has arisen is also assigned in column 414, labelled “Machine Assembly”. This is a particular part of the process where the problem has arisen. For instance, this may be a particular part of the machine that carries out the process where the error has occurred. As shown in Figure 4 example parts of the machine may include the “CUTTING” or “PRINTING” part of the machine assembly.

The processing of the raw error messages shown in table 300 of Figure 3, to arrive at the processed error messages shown in table 400 of Figure 4, may be done automatically by the error analysis device 1201.

The error analysis device 1201 may populate the “Reason” in column 409 based on the “Reason Code” in column 309. This may involve the error analysis device consulting a database of reason codes stored along with their associated meaning. For instance, for the examples shown in Figure 3 and 4 the database may have an entry that indicates that reason code 1.2.1103 relates to an ‘INTERNAL MACHINE STOP’. The database is populated using documentation, such as a user manual, supplied by the machine’s manufacturer which typically include details of what each error code relates to. Alternatively, or in addition, it may be populated from PLC code used in the production line.

The allocation by the error analysis device 1201 of the process stage 411, the problem type 413, the machine assembly 414 and the “MDC message English” descriptor 405 may be through using the reason code 309, source machine 307, and machine ID 305. Though knowing the machine that has transmitted the error message, from the source machine 307 and machine ID 305 data in the raw error message, the data analysis device can pinpoint the process in the production line that has caused the error message to be generated. This in combination with the reason code 309 can be used to determine further details on the cause of the generation of the error message providing details on the problem type 413 the error relates to and providing further details as the “MDC message English” descriptor 405.

Columns 401 and 403, indicating the time values, may be populated automatically from columns 311 and 313. At this stage duplicate error messages may also be deleted, as it is possible that the same error message may be received multiple times. Reducing these multiple entries enables the number of entries in the table 400 to be kept to a more manageable level.

Through breaking up and enhancing the columns shown in Figure 3 into the columns as shown in Figure 4 further details from the error messages can be extracted that were not readily available through just looking at the raw error messages as shown in table 300 in Figure 3.

The processing of the error messages 315a-315g may be further enhanced by user input. Through allowing a worker on the production line to add metadata to the error messages further insight can be obtained from the user that may not be possible to obtain by the data analysis device alone. Figure 5 shows an example user interface 500 which is displayed to the worker by the error analysis device at an input display panel. This may, for instance, be displayed on one of the machines on the production line, or on a handheld computing device operated by the worker. User interface 500 includes a summary of the problems that have occurred during the worker’s shift. Tape 501 shows a series of downtimes 503 505 and the timescale over which they have occurred. The downtimes are separated by times when the production line is operational. As can be seen, downtime 503 is a downtime which has occurred around 1 hour into the worker’s shift for around 1 hour. Downtime 505 is a further downtime that has occurred at around the 2 hour mark. Between downtime 503 and downtime 505 is a period where the production line is running. A number of other downtimes are also shown along the tape 501.

Positioned below the tape 501 is a table 509 of error messages which relate to the downtimes shown in the tape 501. Table 509 includes a column 511 having a description of the breakdown, a column 513 which is the OEE class, a column 515 which includes the reason of the error message, a column 517 which includes the process, sub process and sub-reason for the errors, and columns 519 and 521 which relate to the start time and duration of the problems.

When displayed to the user each of the columns in table 509 may have been populated by the data analysis device 1201 as described above in relation to Figure 4. For instance, the reasons in column 513 may be populated from the details in column 409 of table 400, the process 517 may be populated from the process in column 411 , and the time values in columns 519 and 521 may be populated using the values in columns 401 and 403.

Though displaying these values in this way this enables the error analysis device 1201 to capture data from the worker to gain further insight into the causes of the downtimes.

The user may input data into the user interface using a control panel 507 which is located between the tape 501 and the table 509 in the user interface 500. The control panel 507 include the controls “New”, “Classify”, “Split”, and “Delete”. “New” allows the worker to add a missing error that has occurred that has not been picked up by the error analysis device. “Classify” allows the worker to modify the parameters in table 509 allowing them to classify the error. In particular, the classification may be to add details to column 517 of the cause of the downtime that has resulted in the error and the actions taken to correct them. “Split” may allow the user to edit an error message to split it into a plurality of different errors. For instance, a downtime in tape 501 may be attributed to a number of different causes. Through using the “split” control the user may be able to split the error message in table 509 associated with the downtime into a plurality of different entries each associated with the causes. “Delete” allows the user to delete error messages that are not required. For instance, duplicate messages and/or messages that do not relate to a downtime.

The user may be able to modify each of the elements in the table 500. By selecting a downtime displayed in the tape 501 the user may then be able modify the values in the table 509 through selecting controls 509. Alternatively, the user may restricted to only being able to modify specific columns in the table. For instance, the time values 519 521 may be locked such that the worker is not able to modify them, whereas the process column 517 may be user editable.

Prior to the user being presented with the interface 500 shown in Figure 5 the error messages are arranged into time sequential order based on the time when the error messages originally occurred. This may be based on the values in table 401 and 403 of Figure 4. This step may be necessary due to fact that each error message may be received at the error analysis device 1201 in an order which does not correspond to the order at which the error occurred, which may make the review of the error by the user and the error analysis device difficult. This can enable a primary cause of the error messages to be determined. By arranging the error messages into time sequential order this allows the error messages to be arranged into tapes, such as tape 501 shown in Figure 5.

Figure 6 shows three further examples of tapes 601 603 605. The tapes shown in Figure 6 are based on error messages that have been further processed as described in relation to Figure 4 when compared to the tape shown in Figure 5. The tapes in Figure 6 show downtimes plotted against the time over which they have occurred. Tapes 601 603 605 are arranged into the different stages, such that each different stage has its own associated tape, which are offset in the vertical axis with respect to each other. However, the tape of each stage is plotted against the same time axis so the effect of downtimes between the different stages can be easily viewed. As can be seen in Figure 6, tape 601 relates to error messages that have arisen at the packer, tape 603 relates to error messages that have arisen at the parceller, and tape 605 relates to error messages that have arisen at the wrapper. A key 609 is located above the tracks indicating the reason for the breakdown from columns 405 and 511 of tables 400 and 500. The gaps between the downtimes indicate the periods during which the machine is operating.

By organising the error messages into tapes it is possible to easily visualise the primary cause of the downtimes and its subsequent issues. In the tapes shown in Figure 6 it is clear that error 607 is the root cause of the subsequent downtimes shown in the tapes 600. Error 607 is caused by an error in the packer caused by the cigarette vanes being empty (“CIG VANES EMPTY”). As can be seen each of the error messages in each of the tapes are indirect consequences of this initial error 607. This has had a knock on effect not only causing downtimes at the packing stage but also at the parceller and wrapper stages. As shown in Figure 6 a single error, such as the cigarette vanes being empty, can cause multiple cascading errors resulting in the line being out of action for over 20 minutes. It is desirable to reduce this downtime as this can have a significant impact on the output on the product line. By processing the data in this way this insight can be obtained making it possible to mitigate this error in the future.

Tapes may be created by the error analysis device such that each tape relates to a single primary cause. For instance, the error analysis device may determine the length of each tape, i.e. when a tape should be finished, based on the amount of time that has elapsed since an error was detected. For instance, if a certain time has elapsed between subsequent error messages it may be determined that the later error messages no longer relate to the same primary cause and as such the tape may be ended ready for display and a new tape started. However, other methods may also be used such as having a tape which represents the whole of a worker’s shift (as shown in Figure 5), or one or more production runs. In this way, each tape may not specifically relate to a single primary case.

Though the arrangement of the error messages into tapes the user does not need to be presented with each and every error message as they would conventionally, and instead, as shown in Figure 5 and 6, the user is presented with a tape, with the ability to see the error messages associated with the tape.

Using the tapes shown in Figure 6 not every single tape need be presented to the worker. The worker can be presented only with tapes whose time length is over certain threshold, or if it is determined that the root cause was a user initiated action. For short tapes it is clear that the downtime has been rectified quickly and as such additional insight from the worker on the production line is not required. However, for longer tapes where there have been multiple error messages, and the worker has been unable to re-start the production line quickly, insight on the problems that have occurred and the actions that the user has taken to correct them are required. This is also the case where the user has initiated the downtime through their actions as details of why they have taken this action is required. In addition, a further advantage of displaying the tapes to the user is that it enables then to re-assign the error messages if they feel that the classification of all of the error messages in the tape do not relate to the same primary cause.

The tapes may be stored in a database for use in generating reports of the downtimes and subsequent analysis. Both the tapes that have been annotated by the worker on the production line (those over the threshold time period and/or caused by the worker) and those that were deemed too short to be presented to the worker are stored to provide a full picture of the performance of the line. However, in some arrangements certain tapes may be excluded from being stored in the database.

Figure 7 shows a further example of a series of tapes 700. There is shown a tape for the packer 701 , a tape for the parceller 703, a tape for the tax stamper 707 and a tape for the wrapper 709. However, during the time period over which these tapes span the production line was in standby mode, and was intentionally not operational. The error analysis device 1201 may be programed with details of when the production line is intentionally not operational so that it can ignore tapes that may be generated during pre-planned downtimes time. After having processed the error messages, the error analysis device may present the data from each of the stored tapes in the user interface 900 shown in Figure 9. This may be shown to the workers on the production line in real time or those analysing the line remotely both in real time and at a later time. Interface 900 includes user selectable area 901 which enables each of the different stages (Maker, Packer, Tax Stamper, Parceller, and Wrapper) to be selected. Upon selecting one of the stages in the user selectable area 901 the processed data relating to downtimes of the selected stage can be displayed in the user interface 900. Interface further includes process stage bar chart 903 which shows the total collective time that the processes of the selected stage has experienced a downtime. Key 921 also indicates whether the cause of the downtime is a direct cause or an indirect cause.

A bar chart showing the problem types 905 is also displayed in interface 900. Chart 905 shows the problems experienced by the current selected stage and the collective time over which the problems have been experienced. Further details on the part of the process where the errors occur is provided in chart 907. Chart 907 shows the problems experienced by that particular stage “assembly” (i.e. the particular device component) and the collective time over which the problem has been experienced.

The processed error messages that the data shown in charts 903 905 and 907 have been collected from are shown in table 909. The details of the error messages shown in table 909 include their descriptor and the duration of the error. The duration is further separated into two additional columns: the duration of direct causes and the duration of indirect causes. This enables the total overall time to be displayed at the bottom of the table, in addition to the total time of each of the direct and indirect causes.

A further tab 925 also allows switching between viewing internal machine stops or external machine stops. Internal machine stops are those where the downtime has been caused by the machine stopping itself, whereas an external machine stop is caused by the operator instigating a stop (for instance through pressing a stop button) or the stop being caused by the stoppage of a different machine (upstream or downstream).

Towards the bottom of the user interface 900 is a series of tabs 911 that allow the user to switch between viewing data for different production lines. In Figure 9, line MP57 is being displayed on the display. Through selecting a different tab 911 the user interface can switch between showing data from different production lines. Positioned below the series of tabs 911 is a bar chart 923 showing the duration of the currently selected error across a plurality of days.

The user interface may act as a portion of a report that enables the detailed analysis of the error messages and downtimes across a number of different production lines. For instance, as shown in Figure 9 the “Packer” stage has been selected. As such, chart 903 shows the top six processes in the packer that have experienced downtimes, the durations of these downtimes, and whether they are direct or indirect causes. In the present case, the CIGARETTE/FEEDING process is responsible for the largest amount of direct cause downtimes. Through selecting the CIGARETTE/FEEDING process 913 in chart 903 the top causes of problems relating to this issue are shown in chart 905 with those causing this error highlighted 915. Chart 907 then shows the location within the processes where these errors most often occur, with the most often highlighted 917 being the hopper, and the cigarette quality detection areas which detect missing filters and loose ends. The error messages that correspond to these values are also highlighted 919 in table 909. From this user interface it can quickly be determined which parts of the production line are causing the most downtimes and what the exact causes are. For instance, it can be determined that the cigarette feeding “direct” stops are triggered by material presence and material sensor control limit being reached on the hopper and cigarette quality detection area.

From the downtime analysis performed using interface 900 a set of problem statements can be generated as shown in Figure 10. Figure 10 shows table 1000 which includes details of the most recurring issues leading to the machine downtime as identified from user interface 900. This report may be output to the user for review and editing. Table 1000 shows problem statements for the maker

1001 and packer 1003 of production line “MP59”. Problem statements for other production lines may also be included within the same table 1000, or separate tables may be produced for each production line. Table 1000 includes columns showing the process step 1007, the assembly 1009, MDC message 1011, duration of each downtime 1013, number of downtime events relating to each error 1015 and whether the error is chronic or not. For each stage the problems are each ordered based on the number of events shown in column 1015 that have occurred. This report can be used to identify issues that are recurring on the line to determine which have been causing the largest amount of downtime and to enable a plan to correct them.

Figure 11 shows a portion of the report of the problem setting plan which provides details on the problems, the actions to solve them, and details on whether they have been solved. As can be seen interface 1100 includes a section that corresponds to the errors 1101 from problem statement interface 1000 shown in Figure 10. In this example the production line displayed 1105 is MP86 and the stage shown is the Tax Stamper. Columns relating to the process 1007, assembly 1009 and 1011 are shown, as in interface 1000. User input section 1103 of interface 1100 is for providing the “Daily Directional Settings” for workers. This includes actions that workers are to undertake in order to resolve the errors when they arise. Section 1103 includes columns for action 1107, responsible 1109, due date 1111 , check date 1113, status 1115, and action efficiency 1117. Action 1107 is the action that the worker should take, in the example shown the action is to continue monitoring the error. The person responsible for this, as shown in column 1109 is the electrician, and this is due to be completed by 12/02/2020. Check date column 1113 indicates that this has been checked on 12/02/2020 and that the problem has been solved from status column 1115. The reports as shown in user interfaces in Figures 10 and 11 may be reviewed at a recurring point in time as a base to prioritise corrective actions needed for the production line that is being analysed. For instance, this may be reviewed after 24 hours of production to set the actions that need to be addressed in the upcoming 24 hours. In addition, when the problems are solved this may also be collected in the reports and saved in the database. This may form a library of solved historical issues that can be used if the same problem is encountered again in the future. Due to the nature of the processing, and as the description of errors are not machine specific and have been generalised, the approach taken on one production line to solve errors may be implemented across multiple production lines having different versions of machines, which may provide quick resolution of errors.

It will be appreciated that any of the methods described herein, and any particular step of said methods, can be implemented by a computer or data processing device. Such implementation may take the form of a processor executing instructions stored on a non-transitory computer-readable medium or media, wherein when executed the instructions cause the processor to perform any one or more steps of any of the methods described herein. Individual steps of a method may be implemented by different processors that are all collectively acting in accordance with computer-readable instructions stored on one or more storage media. The processor or processors may be component(s) of error analysis device 1200. A schematic figure of such a data processing device 1300 is shown in Figure 13. Data processing device includes processor 1303 and memory 1301.

Processor 1303 can be operatively coupled to the memory 1301 via a storage interface. Storage interface is any component capable of providing processor 1303 with access to the memory. Storage interface may include, for example, an Advanced Technology Attachment (ATA) adapter, a Serial ATA (SATA) adapter, a Small Computer System Interface (SCSI) adapter, a RAID controller, a SAN adapter, a network adapter, and/or any component providing processor 805 with access to the storage device. Memory 1301 may include, but is not limited to, random access memory (RAM) such as dynamic RAM (DRAM) or static RAM (SRAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), and non-volatile RAM (NVRAM). The above memory types are exemplary only, and are thus not limiting as to the types of memory usable for storage of a computer program.

Having described aspects of the disclosure in detail, it will be apparent that modifications and variations are possible without departing from the scope of aspects of the disclosure as defined in the appended claims. As various changes could be made in the above constructions, products, and methods without departing from the scope of aspects of the disclosure, it is intended that all matter contained in the above description and shown in the accompanying drawings shall be interpreted as illustrative and not in a limiting sense.

As will be appreciated based on the foregoing specification, the above-described embodiments of the disclosure may be implemented using computer programming or engineering techniques including computer software, firmware, hardware or any combination or subset thereof. Any such resulting program, having computer-readable code means, may be embodied or provided within one or more computer-readable media, thereby making a computer program product, i.e. , an article of manufacture, according to the discussed embodiments of the disclosure.

In the above description is the errors have been attributed to downtimes in the production line. However, the errors may not necessarily may be related to downtimes, and the above device and processes may be implement to reduce error that are causing inefficiencies but not necessarily downtimes.

Although the error analysis module shown in Figure 12 has four different modules it may not necessarily be limited as such. The actions performed by each module may be processed together or separately. Figure 3 as described above shows an example raw error message, with their processing using the error analysis device arriving at the processed error messages of Figure 4. However, the error messages shown in Figure 3 are merely examples. The error message that are able to be processed by the error analysis device are not limited to the structure shown and the same processing steps may be applicable for error messages having different formats. Furthermore, the specific details of how the reason, process stage, problem type and machine assembly as described above are only an example of how these columns may be populated from the raw error message. Other methods may also be envisaged.

Claims

CLAIMS:

1. A method, performed by an error analysis device, of reporting and analysing error messages in a manufacturing production line, the method comprising: receiving a plurality of error message, from one or more machines in the production line, each error message relating to an error that has been detected at its associated machine, each error message comprising one or more error codes specific to its associated machine indicating the type of error; processing the plurality of error messages, the processing comprising: assigning a descriptor to each error message through translating the one or more error codes of the error message into a readable format; determining a stage in the production line to which each of the plurality of error messages relate; grouping the plurality of error messages relating to the same stage in the production line; organising the groups of error messages such that they are arranged sequentially to identify a primary cause of the plurality of error messages; generating and displaying a report of the processed error messages, such that a user can take action regarding the errors.

2. The method of claim 1 further comprising, before generating the report: displaying the processed plurality of error messages to a user; receiving user input directed to the displayed processed plurality of error messages allowing the user to modify the processed plurality of error messages.

3. The method of claim 2, wherein the processed plurality of error message are displayed to the user if a duration of the sequentially arranged error messages is above a threshold time period.

4. The method of any preceding claim, wherein the step of processing further comprises assigning a descriptor to each of the plurality of error messages indicating a type of problem that has caused generation of the error message.

5. The method of any preceding claim, wherein the step of processing further comprises classifying whether or not each of the plurality of error messages relates to a manual intervention that has caused generation of the error message.

6. The method of claim 5 when dependent on claim 2, wherein the user input comprises modifying the classification of whether or not the plurality of error messages relates to manual intervention.

7. The method of any preceding claim, wherein each stage in the production line comprise a series of processes, and wherein the step of processing the plurality of error messages further comprises determining the process to which each of the plurality of error messages relate.

8. The method of any preceding claim, each error message comprises a time stamp, the time stamp indicating when the error message was triggered.

9. The method of any preceding claim further comprising for at least one error message of the plurality of error messages identifying a component of the error message’s associated machine that the error message relates, and assigning a descriptor to the error message indicating the component of the machine.

10. The method of any preceding claim, wherein the processing step further comprises identifying duplicate error messages in the plurality of error messages, and deleting the identified duplicate error messages.

11. The method of any preceding claim, wherein the step of assigning a standardised descriptor to each error message through translating the one or more error codes into a readable format comprises translating the error codes through using a reference source having details of the meaning of each error code for that machine.

12. The method of any preceding claim, wherein the report of the processed error messages comprises details of which errors have been responsible for the most downtime of the manufacturing production line.

13. A data analysis device for reporting and analysing error messages in a manufacturing production line, the data analysis device comprising: a receiving module, configured to receive a plurality of error message, from one or more machines in the production line, each error message relating to an error that has been detected at its associated machine, the error message comprising one or more error codes specific to its associated machine indicating the type of error; a processing module configured to process the plurality of error messages, the processing comprising: assigning a standardised descriptor to each error message through translating the one or more error codes of the error message into a readable format; determining a process stage in the production line to which each of the plurality of error messages relate; grouping the plurality of error messages relating to the same process stage in the production line; organising the groups of error messages such that they are arranged sequentially to identify a primary cause of the plurality of error messages; a display module configured to generate and display a report of the processed error messages, such that a user can take action regarding the errors.

14. A computer program product comprising instructions which, when the program is executed by a computer, cause the computer to carry out the following steps: receiving a plurality of error message, from one or more machines in the production line, each error message relating to an error that has been detected at its associated machine, the error message comprising one or more error codes specific to its associated machine indicating the type of error; processing the plurality of error messages, the processing comprising: assigning a standardised descriptor to each error message through translating the one or more error codes of the error message into a readable format; determining a process stage in the production line to which each of the plurality of error messages relate; grouping the plurality of error messages relating to the same process stage in the production line; organising the groups of error messages such that they are arranged sequentially to identify a primary cause of the plurality of error messages; generating and displaying a report of the processed error messages, such that a user can take action regarding the errors.

15. A system comprising: a manufacturing production line, the manufacturing production line comprising one or more machines for manufacturing a product; and a data analysis device for reporting and analysing error messages from the manufacturing production line, the data analysis device comprising: a receiving module, configured to receive a plurality of error message, from one or more machines in the production line, each error message relating to an error that has been detected at its associated machine, the error message comprising one or more error codes specific to its associated machine indicating the type of error; a processing module configured to process the plurality of error messages, the processing comprising: assigning a standardised descriptor to each error message through translating the one or more error codes of the error message into a readable format; determining a process stage in the production line to which each of the plurality of error messages relate; grouping the plurality of error messages relating to the same process stage in the production line; organising the groups of error messages such that they are arranged sequentially to identify a primary cause of the plurality of error messages; a display module configured to generate and display a report of the processed error messages, such that a user can take action regarding the errors.