WO2016174594A1

WO2016174594A1 - Method for condition monitoring and providing a service to a robot

Info

Publication number: WO2016174594A1
Application number: PCT/IB2016/052393
Authority: WO
Inventors: Rajeshwar DATTA
Original assignee: Abb Technology Ltd.
Priority date: 2015-04-27
Filing date: 2016-04-27
Publication date: 2016-11-03

Abstract

The invention provides a method for condition monitoring of a robot and providing a service to the robot. The method comprises identifying one or more patterns associated with an operation of the robot. The one or more patterns are identified from recorded data associated with the operation of the robot, and operation of equipment connected with the robot. The method also comprises collecting real-time data of the robot and the equipment connected with the robot. The method further comprises detecting an occurrence of the identified one or more patterns in the real-time data. In addition, the method comprises determining provisioning of the service to the robot based on the real-time data in response to the occurrence of the identified one or more patterns.

Description

METHOD FOR CONDITION MONITORING AND PROVIDING A SERVICE

TO A ROBOT

FIELD OF THE INVENTION

[001] The invention generally relates to the field of industrial automation, and more specifically to condition monitoring and providing a service to an industrial device such as a robot.

BACKGROUND OF THE INVENTION

[002] An industrial device such as a robot, motor or generator, is typically monitored for determining whether an intervention (e.g. servicing) is required or not. Here, data from the device (e.g. event messages, measurements etc.) is collected and analyzed for determining whether a situation of interest (e.g. a fault) has occurred. Such situations of interests usually trigger an alarm for further actions. In several occasions such monitoring of industrial device and processing of data acquired from the industrial device including the system or environment in which the industrial device is deployed are carried out remotely. In such a remote monitoring and processing centers, the situations of interests and alarms are pre-programmed based on data/patterns observed during a test or experimental conditions. In some other remote monitoring and processing systems, the situations of interest and alarms can be preprogrammed based on run time observations made on several similar industrial devices deployed in one or many remote locations. There is however a limitation in defining (predefining) situations of interest or alarms for a robot or other industrial device, due to the wide variety of applications of the robot or other industrial devices resulting in non- comparable or non-similar behavior of the industrial device with other similar industrial devices in an installed base. Thus, it may not be possible to completely define situations of interest, alarms or other messages, prior to the deployment of a robot or other industrial device and such additional or specific definitions need to be made based on usage of the industrial devices and in due consideration of the environment or condition in which the industrial device is used. Such specific conditions and limitations need to be considered to remotely evaluate the deployed industrial device. Otherwise, even if an alarm condition is identified from processing of data gathered from the industrial device based on general rules formulated without considerations to the specific usage patterns and environment, the alarm or other derived information with the alarm may not be sufficient to act with acceptable statistical confidence and initiate any service action.

SUMMARY OF THE INVENTION

[003] An aspect of the invention provides a method for condition monitoring of a robot and providing a service to the robot. The method comprises identifying one or more patterns associated with an operation of the robot. The one or more patterns are identified from recorded data associated with the operation of the robot, and operation of equipment connected with the robot. The method also comprises collecting real-time data of the robot and the equipment connected with the robot. The method further comprises detecting an occurrence of the identified one or more patterns in the realtime data. In addition, the method comprises determining provisioning of the service to the robot based on the real-time data in response to the occurrence of the identified one or more patterns.

BRIEF DESCRIPTION OF DRAWINGS

[004] The subject matter of the invention will be explained in more detail in the following text with reference to exemplary embodiments which are illustrated in attached drawings in which:

[005] Fig. 1 is a simplified diagram of a system for condition monitoring of a robot and providing a service to the robot; and [006] Fig. 2 is a flowchart of a method for condition monitoring of the robot and providing the service to the robot.

DETAILED DESCRIPTION

[007] An aspect of the invention involves working with existing or easily available information (in many cases excess, irrelevant, and without meaningful descriptions of events), but introducing a layer of analyses on the underlying information. The layer of analyses may be introduced in the controller itself or at an analysis engine. This layer of analysis by definition considers the 'typical' levels of various kinds of information such as events and measurements, calculated for example by taking an 'average' of the levels over preceding days, weeks, or months. Level in the case of the events may imply count per unit time and in the case of measurements may imply the physical or measured value.

[008] The invention also involves presenting in one consolidated frame all relevant information filtered by the previous element. Thus looking at alarms and measurements together provides more context to analyses. The consolidated frame of information could be collected at a Teach Pendant Unit (TPU) or any output device or even a UI to visualize remote information. Particularly, this approach would be useful when events and measurements are 'mapped' to parts of the controller or robot. For example if one finds event x and measurement y significant, and both x and y happen to be mapped to say a component z in the controller, then the case for believing that component z is faulty would gain particular strength. Same can be said when multiple events point to the same component. It must be emphasized that if 'mapping' is not possible the value of presenting the relevant measurements and events in one frame is still valuable.

[009] A variation of deployment can be incorporating a "comparison type utility" in the controller itself. Whenever an undesirable situation occurs on the floor, an operator will have the option to say press a button, and by using the method calculate the deviation from "averages over previous days, weeks, months". The signature (pattern) will be stored as a "signature of interest". In future only such signatures will be signalled as "faults" for the purpose of finding a problematic robot through remote service. In other words in future the only those deviations from "average" will be signalled as faults that have been pre-defined as such. A "comparison" will be performed to check for condition satisfaction with respect to defined "signatures".

[0010] Hence in a way this deployment scenario will enhance the accuracy of finding a problematic robot because it will be able to distinguish between harmless stops such as lunch breaks, weekend off, and any other such events and unwanted downtime. Such distinction although possible to an extent on its own, will receive a boost with input from the operator to "teach" what each robot should consider "fault" deserving attention. The notable difference here is tailored definition of "faults" per robot, and a tailored signature that takes into consideration individual working conditions of each robot like environment, application, and so on.

[0011] An extension of this idea calls for not just "signalling a fault" but also entering the "type of fault" from the floor once the problem is fixed, The association between signatures and actual faults defined individually per robot will lead to derivation of diagnostic fault models for that specific robot or controller. So in a way analyzing a problematic robot is possible for the purpose of knowing what went wrong. So if the signature is seen in future, a tailored error message displaying the real fault for that specific robot, for its specific context, can be displayed rather than error messages today which are pre-defined in the controller from the factory and are common to all robots and do not recognize the use case or context of the robot's operation (environment, application, production schedule and so on).

[0012] When this is done for a signature which covers a long duration such as hours, days, or weeks, then as the signature develops it may be possible to signal an impending problem. An alternate deployment scenario would be to deploy the method on the remote service server instead of building it into the controller. This would make the benefits relevant only to remote service related robots.

[0013] Referring to Fig. 1, which illustrates a simplified diagram of a system (100) for condition monitoring of an industrial device and providing a service to the industrial device. The industrial device may be a robot (102). It should be noted that the invention is not limited to a robot, and is applicable for any other industrial device such as motor, generator etc. The robot may be a robot for welding, painting, or other application.

[0014] The robot may be connected with other equipment such as, but not limited to, a sensor (104), a Programmable Logic Controller (PLC 106), and a Teach Pendant Unit (TPU 108). For example, in case of a packaging system, a robot may be operationally coordinated with a PLC of a conveyor system and other sensors that provide measurements (e.g. speed). Thus, the robot and the other equipment (devices) may be part of an automation system (110) and form an environment for the robot. For example, there may be an assembly line, a packaging system and so forth that form the environment for the deployed robot and the condition/behavior of the robot can obtain specific traits based on its usage in the environment

[0015] The system has a controller or an intelligent electronic device (112) for recording data associated with the robot and the other equipment associated with the operation of the robot in the robot environment. The gathered data can include event information (e.g. event messages) from the robot, measurements (e.g. temperature, speed etc.) from the robot or sensors in the robot environment, user inputs related with the operation of the robot or other equipment, and ERP data (e.g. associated with plan of operation of the robot). It should be apparent that the data is associated with the operation of the robot and other equipment connected and associated with the operation of the robot. [0016] Additionally, the robot system may have a server (114) supporting the intelligent electronic device to store data or process data. The server may be located in the robot environment or in a remote location from where the remote monitoring is performed. The server additionally has modules to record information gathered from processing of robot in consideration with specific usage of the robot or/and robot environment, and also the information/inputs provided through manual monitoring of the gather data from the robot system. The specific information processed with the server or/and manually provided are here referred as contexts stored in a memory (116), and various processing performed by the server is provided with an analysis engine (118).

[0017] The contexts may be defined and stored according to corresponding user inputs. In one embodiment, the context are defined as rules and includes newly identified rules based on manual observations made in the gather data in response to the alarms. Thus, these contexts are defined post deployment of the industrial devices. The analysis engine may be configured to identify one or more patterns from recorded data associated with the operation of the robot, and operation of equipment connected with the robot. The analysis engine may further detect occurrence of the identified one or more patterns in real-time data, which may be used for determining whether service should be provisioned or other intervention made for the robot.

[0018] Refering now to Fig. 2, which illustrates a method for condition monitoring and providing a service to the industrial device. The method may be implemented by one or more of the controller and with the analysis engine of the server of Fig. 1 along with the pre-defined/newly defined contexts (rules).

[0019] At 202, one or more patterns associated with an operation of the robot are identified manually based on a study of an alarm condition together with the gathered data. For example, the operation could be painting, welding, a sub-process thereof etc., and a pattern may be a data characteristic of a robot and other equipment representing a state or a situation of interest (signature of interest) associated with the robot in consideration to the robot environment/usage. Such one or more patterns associated with an operation of the robot may also be identified using the analysis engine in the server to assist identification of specific patterns associated with the robot based on its usage or environment.

[0020] The one or more patterns are identified from recorded data associated with the operation of the robot and operation of equipment connected with the robot. Consider a case where a robot in a conveyor system is being monitored. Here, data such as robot identifier, log time and date, location, event type etc. can be recorded along with data of conveyor motor, PLC commands etc. The one or more patterns may be identified by taking averages, correlation etc. For example, the total time motors have been off in a calendar day, can be measured by the sum total of all differences between "motors off and "motors on" time stamps.

[0021] In one embodiment, each pattern of the one or more patterns is identified with a user input according to a context associated with the operation of the robot and stored, thus enabling an already defined context (predefined context) for future use/processing of new data (real time data) associated with the robot. For example, a user may tag a fault or other event, which may call for servicing or repair, based on the application context. Also, such contexts may be configured in the server.

[0022] At 204, real-time data of the robot and the equipment connected with the robot are collected. An occurence of the identified one or more patterns (including the patterns based on predefined context) may be detected at 206. For example, a data characteristic similar to a fault may be seen. Thereafter, at 208, it is determined whether a service should be provisioned or not. This may be based on the real time data. For example, the average performance in the preceding few weeks may be taken as a reference point to decide whether or not the behavior 'today' is an anomaly. Consider a case where a motor is being monitored. Here, stoppage time can be taken as an indicator of 'downtime' and can be determined by (i) taking the summation of time stamp differences between 'motors on' and 'motors off in the period of interest (ii) doing the same as (i) but for 'program start' and 'program stop'.

[0023] There could be variations in how the pattern is determined. One implementation could be to use "Coefficient of Variation (COV)" of the error count in the preceding weeks, as a measure of "typical variation", and flag deviation greater than this COV, where deviation of interest is the difference between the count 'today' and the average count of the preceding weeks. Likewise this approach could be followed for a variety of indices and not just the error count.

[0024] A contextual definition of a situation of interest (e.g. fault) can be stored to identify a pattern. For example, by pressing a button on a Teach Pendant Unit (TPU) to signal a situation of interest, a user can store analyses preceding a "fault" as a reference signature. This may help when the situation is replicated in future, where the analysis engine (or controller) may trigger a message for help. In addition to "signaling a fault" the "type of fault" from the floor may also be indicated, once the problem is fixed. The association between signatures and actual faults defined individually per device (e.g. robot) will lead to derivation of diagnostic fault models for that specific robot or controller. This could be particuarly helpful for cases where there are a plurality of industrial devices spread across different locations.

[0025] This approach would be useful when events and measurements are 'mapped' to parts of the controller or robot. For example if it is found that event x and measurement y are significant, and both x and y happen to be mapped to say a component z in the controller, then the case for believing that component z is faulty would gain particular strength. Same can be said when multiple events point to the same component.

[0026] The invention enables recognizing interesting contexts deserving an action as encountered during the day to day operations of an industrial device. The fact that these contexts are recognized post deployment means that contexts relevant to one piece of industrial device in one setting being used for one purpose may be different from contexts encountered by an identical piece of equipment in another setting being used for another purpose. Hence these contexts are very specific to use of an equipment in one setting for one purpose. Herein lies the power to capture those contexts which are difficult to visualize and therefore pre-define for any equipment as standard situations which need a standard response.

[0027] Thus, for an industrial device, the method enables to learn in real time (e.g. with some manual help) as to what contexts encountered in day to day operations that require an intervention and which ones do not. This may be done by initiating an action that 'records' such interesting contexts and identifies them with an actionable handle. This allows an appropriate response to be associated with a taught context, to realize the benefits of the method. Such a response could be an intervention regarding fixing the equipment, improving its performance, or simply providing value-added services to the user of the equipment.

Claims

1. A method for condition monitoring of a robot and providing a service to the robot, the method comprising:

identifying one or more patterns associated with an operation of the robot, from recorded data associated with the operation of the robot, and operation of equipment connected with the robot;

collecting real-time data of the robot and the equipment connected with the robot;

detecting an occurrence of the identified one or more patterns in the real-time data; and

determining provisioning of the service to the robot based on the real-time data in response to the occurrence of the identified one or more patterns.

2. The method of claim 1, wherein each pattern of the one or more patterns is identified with a user input according to a predefined context associated with the operation of the robot.

3. The method of claim 2, wherein the predefined context is configured in a server associated with the robot.

4. The method of claim 2, wherein the user input comprises a command provided by pressing a button on a teach pendant unit asscoiated with the robot.

5. The method of claim 1, wherein a pattern of the identified one or more patterns is associated with a type of fault.