CN111882084A

CN111882084A - Method and apparatus for performing maintenance on field devices in a plant

Info

Publication number: CN111882084A
Application number: CN202010730397.5A
Authority: CN
Inventors: 王琪; 于禾; 周文晶; 陈俊杰; 张海涛; 龚锦标; 于庆明; 张见平; 李虎; 张宇乐; 宋振国
Original assignee: Siemens Factory Automation Engineering Ltd
Current assignee: Siemens Factory Automation Engineering Ltd
Priority date: 2020-07-27
Filing date: 2020-07-27
Publication date: 2020-11-03

Abstract

An embodiment of the present disclosure provides a method for performing maintenance on a field device in a plant, including: acquiring device data of the field device, wherein the device data represents a current event of the field device; generating recommended actions for the events based on the device data using a knowledge model of the field device, wherein the knowledge model includes possible event types for the field device and corresponding actions for each event type; and providing the recommended action to perform maintenance on the field device. By the method, the knowledge integration level and the transparency of the field device are improved, and accurate maintenance suggestions can be recommended for field personnel. The field personnel do not need to spend energy and time to learn the maintenance manuals of different field devices, and can also quickly and effectively maintain the field devices, so that the maintenance accuracy and efficiency are ensured, and the production efficiency of a factory is improved. In addition, as knowledge models continue to expand and accumulate knowledge, more intelligent and accurate recommendations can be achieved.

Description

Method and apparatus for performing maintenance on field devices in a plant

Technical Field

The present disclosure relates to the field of industrial manufacturing, and more particularly, to methods, apparatus, computing devices, computer-readable storage media, and program products for maintaining field devices in a plant.

Background

The automotive industry is currently highly automated and, in order to increase productivity and efficiency, many advanced field devices are used in the automotive industry, such as robots, AGVs (automated guided vehicles), and the like. However, as field devices become more efficient and intelligent, maintenance of these field devices remains a significant challenge. Poor maintenance will affect the capacity of the plant, and frequent production interruptions will also cause significant losses to the plant.

Some factories have built data anomaly alarm systems to assist in the maintenance of field devices. Such systems generate an exception alarm by setting data thresholds, generate maintenance work orders and dispatch field personnel to the field to inspect and maintain the field device. There are also some field device manufacturers that currently provide maintenance systems for individual field devices that integrate maintenance information support and auxiliary maintenance for the field device.

Disclosure of Invention

Existing data anomaly alarm systems simply identify the occurrence of an anomaly while a large number of field devices of different types and from different manufacturers exist in the plant, thus still placing high maintenance pressure on the field personnel. Moreover, different field devices have different and separately stored maintenance manuals, which makes it difficult for field personnel to query and locate the cause of an abnormal event, as well as to learn the maintenance knowledge of the different field devices with a great deal of effort. In addition, expert knowledge and experience are difficult to popularize and apply.

While the maintenance system for individual field devices can support and assist maintenance, it integrates only the maintenance information for a particular field device, and thus the maintenance system for these individual field devices is decentralized over the entire plant, rather than a unified maintenance system. Furthermore, maintenance information in the maintenance system of a single field device cannot be flexibly expanded and accumulated.

A first embodiment of the present disclosure presents a method for performing maintenance on a field device in a plant, comprising: acquiring equipment data of the field equipment, wherein the equipment data represents a current event of the equipment; generating recommended actions for the events based on the device data using a knowledge model of the field device, wherein the knowledge model includes possible event types for the field device and corresponding actions for each event type; and providing the recommended action to perform maintenance on the field device.

By establishing knowledge models for field devices in a factory, maintenance knowledge of different knowledge sources of the field devices can be integrated together, and knowledge integration level and transparency of the field devices are improved. In addition, the current equipment data of the field equipment can be analyzed by using the knowledge model, so that accurate maintenance suggestions are recommended for field personnel. The field personnel do not need to spend time and energy to learn the maintenance manuals of different field devices, and can also utilize the maintenance knowledge of different knowledge sources contained in the knowledge model to quickly and effectively maintain the field devices, thereby ensuring the accuracy and the high efficiency of maintenance and improving the production efficiency of factories. In addition, the knowledge model is easy to expand, and more intelligent and accurate recommendation can be realized along with the continuous expansion and accumulation of knowledge of the knowledge model.

A second embodiment of the present disclosure provides an apparatus for performing maintenance on a field device in a plant, comprising: a data acquisition unit configured to acquire device data of the field device, the device data representing an event currently occurring at the field device; an action recommendation unit configured to generate a recommended action for the event based on the device data using a knowledge model of the field device, wherein the knowledge model includes possible event types for the field device and a corresponding action for each event type; and an action providing unit configured to provide a recommended action to perform maintenance on the field device.

A third embodiment of the present disclosure proposes a computing device including: a processor; and a memory for storing computer-executable instructions that, when executed, cause the processor to perform the method of the first embodiment.

A fourth embodiment of the disclosure proposes a computer-readable storage medium having stored thereon computer-executable instructions for performing the method of the first embodiment.

A fifth embodiment of the disclosure proposes a computer program product, tangibly stored on a computer-readable storage medium, and comprising computer-executable instructions that, when executed, cause at least one processor to perform the method of the first embodiment.

Drawings

The features, advantages and other aspects of various embodiments of the present disclosure will become more apparent by referring to the following detailed description in conjunction with the accompanying drawings, in which several embodiments of the present disclosure are shown by way of illustration and not limitation, wherein:

FIG. 1 illustrates a method for performing maintenance on field devices in a plant in accordance with one embodiment of the present disclosure;

FIG. 2 illustrates a system architecture diagram for implementing the method of FIG. 1, according to one embodiment of the present disclosure;

FIG. 3 illustrates a workflow for field device maintenance using the system of FIG. 2;

FIG. 4 illustrates a schematic diagram of a portion of an onto-model of a field device established in the embodiment of FIG. 2;

FIG. 5 is a schematic diagram of a portion of an AGV knowledge model established in the embodiment of FIG. 2;

FIG. 6 is a diagram illustrating mapping and grouping of current events and historical events into a vector space in the embodiment of FIG. 2;

FIG. 7 is a schematic diagram illustrating a rule-based action query in the embodiment of FIG. 2;

FIG. 8 illustrates a schematic diagram of relationship-based action inference in the embodiment of FIG. 2;

FIG. 9 illustrates an apparatus for performing maintenance on field devices in a plant in accordance with one embodiment of the present disclosure; and

FIG. 10 illustrates a block diagram of a computing device for performing maintenance on field devices in a plant in accordance with one embodiment of the present disclosure.

Detailed Description

Various exemplary embodiments of the present disclosure are described in detail below with reference to the accompanying drawings. Although the exemplary methods, apparatus, and devices described below include software and/or firmware executed on hardware among other components, it should be noted that these examples are merely illustrative and should not be considered as limiting. For example, it is contemplated that any or all of the hardware, software, and firmware components could be embodied exclusively in hardware, exclusively in software, or in any combination of hardware and software. Thus, while the following describes example methods and apparatus, persons of ordinary skill in the art will readily appreciate that the examples provided are not intended to limit the manner in which the methods and apparatus may be implemented.

Furthermore, the flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of methods and systems according to various embodiments of the present disclosure. It should be noted that the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

As used herein, the terms "include," "include," and similar terms are open-ended terms, i.e., "including/including but not limited to," meaning that additional content may also be included. The term "based on" is "based, at least in part, on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment," and the like.

FIG. 1 illustrates a method for performing maintenance on field devices in a plant according to one embodiment of the present disclosure. Referring to fig. 1, method 100 begins at step 101. In step 101, device data of a field device is acquired, the device data representing an event currently occurring at the device. The field device may be any device in a factory that is in an industrial field, such as a device used for production, manufacturing, and transportation. Each field device includes a plurality of components, and a current occurrence of an event in a field device indicates that an abnormal condition is currently occurring in a component of the field device. The device data includes event types of events that occur, such as motor temperature anomalies, motor vibration anomalies, industrial fieldbus errors, and the like. Field device maintenance includes not only the types of periodic and non-periodic maintenance (e.g., predictive maintenance) performed on a field device or its components prior to their failure, but also repairs to the field device or its components as necessary.

In some embodiments, the method of fig. 1 is performed by a server device based on a web application. The server device may be an on-site server located in the plant or a cloud server external to the plant. A plurality of edge devices networked to the server device receive real-time process data from the plurality of field devices, respectively. The edge device judges whether an abnormal condition occurs in a certain part of the field device according to the received process data and a preset data threshold value, namely whether an event occurs. If an event occurs, the edge device determines the event type (e.g., motor temperature anomaly) of the currently occurring event and generates device data. In addition to the event type of the currently occurring event, the device data also includes field device identification and current state data of the field device. The status data is used to indicate the status of the field device, such as the position, speed, load condition, current value, voltage value, motor temperature value, motor vibration value, etc. of the field device. The edge device then uploads the device data over the network to an event database at the server device or at other devices. To form a unified maintenance system, the device data for all field devices is stored in a unified event database. The server device may periodically access the event database to read device data for a field device. In other embodiments, determining whether an event has occurred and determining the event type of the event may be performed by a server device.

With continued reference to FIG. 1, in step 102, recommended actions for the event are generated based on the device data using a knowledge model of the field device, wherein the knowledge model includes possible event types for the field device and corresponding actions for each event type. To build a knowledge model (or known as a knowledge graph), an onto-model related to maintenance of a field device may first be built through any existing onto-model creation software or tool. The onto-model describes all the classes (abstractions) and relationships between them that are relevant to the maintenance of the field device. Classes may include device types, components, events, actions, means, people, tasks, states, other devices/components related, and the like. For example, the equipment types may include moving equipment, which in turn may include the class of AGV equipment, and elevator equipment; the components may include parent components, child components, and the like. Relationships may include whole and part relationships, generic relationships, attribute relationships, and the like. For example, there are generic relationships between a moving machine and an AGV machine, overall and partial relationships between an AGV machine and its components, and attribute relationships between actions and means and personnel. The action may be a maintenance/repair action required due to the occurrence of an event or a maintenance action periodically required by a component of the field device.

After the ontology model is established, for each field device, specific instances of the classes of device types, components, events, actions, means, people, tasks, states, other devices/components related to the field device are taken as nodes, and the ontology model is instantiated by taking the relationships between the instances as the relationships between the nodes, so that a knowledge model of the field device is generated and stored in a knowledge database. The knowledge database may, for example, be a graph database adapted to embody the nodes and the relationships between the nodes. Thus, the knowledge model includes a hierarchy of field devices, possible event types for the field devices and corresponding actions for each event type, and associations of the field devices or components thereof with other devices or components. The knowledge model may also include periodic maintenance actions required for the components of the field device.

Specific instances in the knowledge model may be from knowledge source data related to the field device, such as a maintenance manual for the field device, maintenance/repair records for the field device, expert maintenance knowledge for the field device, and so forth. Maintenance manuals are typically provided by device manufacturers and include hierarchical information about field devices, status data about events and corresponding field devices that may occur on a field device, and maintenance/repair actions and periodic maintenance actions directed by the device manufacturer for the event. The maintenance/repair record of the field device generally includes an event that occurred in the production process of the plant, status data corresponding to the field device, maintenance/repair actions of field personnel for the event, periodic maintenance actions for the components of the field device, and the like. Expert maintenance knowledge of a field device typically includes content such as an expert's judgment of the occurrence of various events based on status data of the field device, maintenance/repair actions taken with respect to various events, and periodic maintenance actions on field device components.

In some embodiments, method 100 further comprises (not shown in fig. 1): obtaining knowledge source data related to a field device; and generating a knowledge model of the field device based on the knowledge source data. Since the knowledge source data is usually stored dispersedly in various places or is grasped by the experts themselves, the knowledge source data can be integrated together by means of document import in a common format (e.g., word document, PDF document, Excel document, etc.), API interface acquisition, manual input, and the like. The knowledge model for a field device may be generated by semantic searching and/or manually looking up the data from these knowledge source data that is needed to build a knowledge model for a field device, and then using this data as a specific instance of a class in the ontology model. When the knowledge model is established, priority sequencing can be carried out on various knowledge source data, so that the knowledge model is more accurate and effective. For example, expert maintenance knowledge may be set to have the highest priority, maintenance/repair records for a field device may be set to have the next highest priority, and a maintenance manual for the field device may be set to have the lowest priority. The knowledge model may be re-established periodically or when needed.

As mentioned above, the knowledge model of a field device integrates the hierarchy of the field device, the possible event types for the field device and the corresponding actions for each event type, and the relevant knowledge of the association of the field device or its components with other devices or components. Accordingly, recommended actions for the currently occurring event may be generated based on the current device data for the field device using the knowledge model. The corresponding action for an event type in the knowledge model may be one or more actions, each of which may include the means and personnel (e.g., repairman, technician) to implement the action. Likewise, the recommended action may also be one or more actions. Additionally, recommended actions required for periodic maintenance of components of the field device can also be generated using the knowledge model. The periodic maintenance action for a component in the knowledge model may also be one or more actions, each of which may include the means, frequency, and personnel (e.g., serviceman, technician) to perform the action. In some embodiments, each action in the knowledge model is labeled with a priority index, and thus, the generated recommended actions may be prioritized before outputting the recommended actions.

In some embodiments, generating a recommended action for the event based on the device data using the knowledge model of the field device further comprises: inquiring corresponding actions of the event type in the knowledge model according to the event type of the event; and generating a recommended action based on the corresponding action. Specifically, rules between components-event types-actions are established in advance, and recommended actions for events are generated through action queries based on the rules. The rule may be "a component has an event of a certain event type that requires a certain action, and the action is applied to the component". And inquiring a corresponding action of the event type in the knowledge model according to the event type included in the equipment data, wherein the corresponding action is an action applied to a component where the event occurs. And after the corresponding action is inquired, taking the corresponding action as a recommended action. In this manner, the recommended action is an action in the knowledge model that is related to a particular event type and a particular component. The recommended action may be saved in the event memory mentioned above.

In some embodiments, generating the recommended action for the event based on the device data using a pre-established knowledge model of the field device further comprises: determining associated devices or components related to the event based on the knowledge model; according to the event type of the event, inquiring the corresponding action of the event type and the associated action of the associated equipment or component in the knowledge model; and generating a recommended action based on the corresponding action and the associated action. In these embodiments, the recommended actions for the event are generated by relationship-based action inference. In some cases, an event occurring at one component of a field device may be related to other components of the field device or other devices in the environment or components of other devices. For example, an error in the industrial fieldbus of the AGV may be a failure of the industrial fieldbus itself, a failure of a sensor connected thereto or even a failure of the entire navigation system including the sensor. Additionally, a simultaneous occurrence of an event by multiple components of a field device may be associated with the same parent component to which the multiple components belong. For example, a simultaneous breakage of two axes on a robotic arm may be a failure of the entire robotic arm. Thus, in addition to the component where the event occurred, there is a need to determine the associated device or component related to the event. The associated device or component may be a component on the same field device as the component where the event occurred, or may be a component on another device or other device. After the device data is obtained, a component corresponding to the event type is inquired in the knowledge model, and the associated device or component is determined according to the association relation between the component and other devices or components in the knowledge model. Thereafter, the corresponding action for the event type and the determined associated action for the associated device or component are queried and taken as recommended actions. In this manner, the recommended action is an action in the knowledge model that is related to the plurality of components. Also, the recommended action may be saved in the event memory mentioned above.

In some embodiments, generating a recommended action for the event based on the device data using the knowledge model of the field device further comprises: obtaining historical recommended actions for similar historical events, wherein the historical recommended actions were previously generated according to a knowledge model; and generating a recommended action based on the historical recommended action. In these embodiments, a recommended action for an event is generated based on the event similarity identification. As described above, the event database maintains recommended actions for each event in addition to the device data provided by the edge devices. Thus, all historical recommended actions for historical events are saved therein. These historical recommended actions for similar historical events may be used to provide a reference for the current event. The event type of the similar historical event may be the same as the event type of the current event, but the historical state data of the field device at the time of the similar historical event is similar to the state data of the current field device.

In some embodiments, the method 100 further comprises: determining a historical event of the same event type as the event; and selecting similar historical events from the historical events based on the status data. And querying historical state data of a plurality of historical events which occur on the same type of field device and have the same event type in the event database according to the event type and the field device identification in the device data. The historical events are grouped (or classified) according to the historical state data corresponding to the historical events, and a group (or a class) of the historical events with the historical state data closest to the current state data is selected. And taking the selected group of historical events as similar historical events. In other embodiments, similar historical events may be selected in other ways.

After similar historical events are determined, one or more historical recommended actions for the similar historical events are obtained. As described above, the historical recommended actions are previously generated from the knowledge model and saved in the event database. After that, the obtained historical recommended action is taken as a recommended action.

In some embodiments, each action in the knowledge model is labeled with a priority index, and thus the historical recommended actions generated are also labeled with priority indices. When there are a plurality of history recommended actions similar to the history event, the history recommended actions may be sorted according to the priority index, and the sorted history recommended actions may be used as recommended actions.

In some embodiments, recommended actions for an event may be generated by any two or all of rule-based action queries, relationship-based action inference, and event similarity identification simultaneously. In these embodiments, after a plurality of recommended actions are generated in different manners, the recommended actions may be prioritized according to the priority index labeled for each action, and the ranked recommended actions may be stored in the event database as final recommended actions.

Next, in step 103, recommended actions are provided to perform maintenance on the field device. As described above, the generated recommended actions are saved in the event database. The field personnel are notified via a client device (e.g., a handheld device) of events and recommended actions occurring at the field device. In addition to recommended actions for events, recommended actions for maintenance may be sent to field personnel periodically, as often as required for periodic maintenance of field device components in the knowledge model. And the client device receives the events and the recommended actions generated by the field device and displays the events and the recommended actions in a webpage form. And the field personnel go to the field equipment to check the occurred event, and the field equipment is maintained by referring to the recommended action.

In some embodiments, method 100 further comprises (not shown in fig. 1): acquiring feedback data of the recommended action; and adjusting the knowledge model based on the feedback data. After maintenance of the field device, the field personnel may feedback on the recommended action, which may select the action actually taken among the recommended actions, or enter a new action when the recommended action is not used. These feedback data are sent via the client device and stored in the event database. The server device periodically reads the event database and obtains feedback data for the recommended action therefrom. The feedback data may be augmented and/or updated as a new knowledge source to the knowledge model of the field device.

In some embodiments, adjusting the knowledge model based on the feedback data further comprises: modifying and/or changing the priority of the corresponding action for the event type of the event in the knowledge model. If the feedback data includes new actions entered by the field personnel, corresponding actions for that event type may be added to the knowledge model. If the feedback data includes the action actually taken that the field person selected in the recommended action, the priority index of the action actually taken may be increased in the knowledge model. Additionally, in some cases, one or more actions with lower priority indices may also be deleted in the knowledge model. In some embodiments, the historical event grouping (or classification) algorithm may also be adjusted using the feedback data to obtain similar historical events that are more similar to the current event in the future.

By adjusting the knowledge model based on feedback data of field personnel, the knowledge model can be continuously expanded and improved, thereby further improving the accuracy of recommended actions and the maintenance efficiency of field devices, and further reducing the dependence on personal experience.

In the above embodiments, by building a knowledge model for each field device in the plant, maintenance knowledge of different knowledge sources for the field device can be integrated together, and device data for the field device can be analyzed using the knowledge model, thereby accurately recommending maintenance recommendations for field personnel. The field personnel do not need to spend energy and time to learn the maintenance manuals of different field devices, and can utilize the maintenance knowledge of each knowledge source contained in the knowledge model to better understand the root cause of the fault and quickly and effectively maintain the field devices, so that the knowledge integration level and the transparency of the field devices are improved, and the accuracy and the efficiency of maintenance are ensured. Moreover, the knowledge models and the event data of all the field devices are stored in the unified database, so that a unified field device maintenance system can be realized in a factory, and the production and maintenance efficiency of the whole factory is improved. In addition, the knowledge model is easy to expand, and more intelligent and accurate recommendation can be realized along with the continuous expansion and accumulation of knowledge of the knowledge model.

The method of FIG. 1 for performing maintenance on field devices in a plant is described below with reference to a specific embodiment.

This embodiment is also described with reference to fig. 2-8. FIG. 2 illustrates a system architecture diagram for implementing the method of FIG. 1, and FIG. 3 illustrates a workflow for field device maintenance using the system of FIG. 2, according to one embodiment of the disclosure.

In FIG. 3, the workflow 300 first includes step 301 of obtaining knowledge source data related to a field device and generating a knowledge model of the field device based on the knowledge source data. Referring to FIG. 2, knowledge source data is acquired by knowledge acquisition module 20 in system 200. The system 200 is deployed at a server device within the plant or at a cloud device outside of the plant. In the present embodiment, the knowledge acquisition module 20 includes three sub-modules, which are a manual reading module 201, a record reading module 202, and an expert knowledge reading module 203. The manual reading module 201 is used for acquiring data from a maintenance manual of the field device, the record reading module 202 is used for acquiring data from a maintenance/repair record of the field device, and the expert knowledge reading module 203 is used for acquiring data from an expert by manually inputting or reading a document. In other embodiments, data may also be obtained from other knowledge sources.

The sub-modules of the knowledge acquisition module 20 provide the acquired knowledge source data to the model generation module 21. The model generation module 21 establishes an ontology model relating to maintenance of the field device in advance before generating a knowledge model of the field device. FIG. 4 shows a schematic diagram of a portion of an onto-model of a field device built in the embodiment of FIG. 2. Referring to fig. 4, a device type, an elevator device class, a moving device class, an AGV device class, a component, a sub-component, an event, a joint event, an action, a measure, a frequency, a person, a status, a workstation, a task, and a region all belong to a class, and a connection line between the classes indicates a relationship therebetween. The relationships between classes include whole and part relationships, generic and attribute relationships, and the like. For example, in fig. 4, both the elevator class and the sports class belong to subclasses of equipment types, the elevator class has components with subcomponents, the AGV class belongs to subclasses of the sports system class, the AGV class has components with subcomponents. Sub-components are events, events require actions, actions include instruments and personnel. Multiple sub-components may also be joined by a join event that forms an event that occurs to a parent component of the multiple sub-components, both of which require action. In addition, the component also applies actions (such as scheduled maintenance actions) including means, frequency, and personnel without requiring event triggers. The AGV device class has a state that is located in a workstation and has a task that works in the workstation, the workstation being located in a zone. Thus, the onto-model of a field device describes all classes and relationships between them that are relevant to the maintenance of the field device.

The model generation module 21 includes three sub-modules, a device description module 211, an event and action description module 212, and a system relationship description module 213. The device description module 211 extracts the hierarchy information of the field devices in the knowledge source data and instantiates the associated classes in the onto-model. The event and action description module 212 extracts event types and corresponding actions for the event types for events that may occur with the field device in the knowledge source data and regular maintenance actions for the field device and instantiates the associated classes in the ontology model. The system relationship description module 213 extracts associations of field devices and their components with other devices or components in the knowledge source data and instantiates the relevant classes in the onto-model. The instantiated onto-model constitutes a knowledge model (or known as a knowledge graph) of the field device.

When the knowledge model is established, if corresponding actions of the same event type are different in different knowledge sources, the different actions are prioritized, different priority indexes are labeled, and the different priority indexes are included in the knowledge model. In this embodiment, actions from expert maintenance knowledge are labeled with the highest priority index, actions from maintenance/repair records are labeled with the next highest priority index, and actions from maintenance manuals are labeled with the lowest priority index. The model generation module 21 builds such a knowledge model for each field device in the plant that needs maintenance and saves the built knowledge model of the field device in the database 22. Knowledge models may be derived from the graph database 22 for use in other systems. The knowledge model may also be re-established or expanded on its basis as needed. The established knowledge model may be displayed via visualization module 23 for manual modification and/or viewing.

FIG. 5 is a schematic diagram of a portion of an AGV knowledge model established in the embodiment of FIG. 2. As shown in fig. 5, the knowledge model of the facility AGVs 1 describes the hierarchy of AGVs 1, the possible event types and corresponding actions for each event type for the AGVs 1, and the association between components of the AGVs 1. The following describes a procedure of recommending a maintenance operation by taking AGV1 as an example.

Returning to FIG. 3, step 302 includes obtaining equipment data for the AGV1 that represents the current occurrence of the event for the AGV 1. Real-time process data is received by the edge device from AGV1 and a determination is made as to whether an event has occurred. If an event occurs, the event type of the event is determined by the edge device and device data is generated. The device data includes device identification AGV1, event type, and status data for AGV 1. In the present embodiment, event types may include motor temperature anomalies, motor vibration anomalies, industrial fieldbus errors, and the like, and status data may include position, speed, load, motor temperature values, motor vibration values, and the like, of AGV 1. The edge device then uploads the device data to the event database 24 of the system 200. In addition to the currently obtained device data, historical device data for historical events and historical recommended actions for historical events are also maintained in the event database 24. In addition, feedback data of the field personnel to these recommended actions is also stored in the event database 24.

Next, step 303 includes generating recommended actions for events occurring with the AGV1 based on the device data using a knowledge model of the AGV 1. This step is accomplished by the event processing module 25 and the action recommendation module 26 of the system 200. Event processing module 25 obtains device data for AGV1 from event database 24 and provides the device data to action recommendation module 26. The action recommendation module 26 includes three sub-modules, an event similarity identification module 261, a rule-based action query module 262, and a relationship-based action inference module 263. They each generate recommended actions for events occurring to AGV1 based on the device data, including specific instruments and required personnel.

The event similarity identification module 261 queries the similar historical events from the event database 24 via the event processing module 25. Specifically, taking the event type of the event currently occurring by AGV1 as an example of a motor vibration abnormality, event similarity identification module 261 queries, via event processing module 25, historical device data and corresponding historical recommended actions, in event database 24, where the device type is AGV and the event type is a motor vibration abnormality. These historical device data indicate that the same type of historical event occurred on the same type of field device (i.e., AGV in this embodiment). Thereafter, the event similarity identification module 261 groups the historical events according to the historical state data in the historical device data using a preset algorithm. FIG. 6 shows a schematic diagram of mapping current events and historical events into vector space for grouping in the embodiment of FIG. 2. As shown in fig. 6, these historical events are divided into three groups A, B and C according to the historical state data, and are represented by different shapes, respectively. "x" indicates a current event, which is closest to the historical events of group a, and is therefore included in group a. Meanwhile, the historical events of the group A are selected as similar historical events of the current event. After determining similar historical events, the event similarity identification module 261 obtains a plurality of historical recommended actions for the similar historical events, and sorts the historical recommended actions according to their priority indexes to serve as recommended actions.

Rule-based action query module 262 queries the knowledge model of AGV1 for the corresponding action for the event type based on the event type included in the device data and takes the corresponding action queried as the recommended action. Specifically, and again taking the event type of the current event of AGV1 as an example of a motor vibration anomaly, FIG. 7 shows a schematic diagram of a rule-based action query in the embodiment of FIG. 2. As shown in fig. 7, the rule established in advance is "if a motor vibration abnormality occurs in the motor 1 and an action for the motor vibration abnormality is required for the motor 1, the action is applied to the motor 1". The action for the motor vibration abnormality may be, for example, checking whether there is an external impact or debris. Rule-based action query module 262 queries the type of motor vibration anomaly event and the corresponding action for the motor vibration anomaly from the current event's event type in the knowledge model of AGV1 shown in FIG. 5 as a recommended action to apply to motor 1.

Relationship-based action inference module 263 queries the knowledge model of AGV1 for the event type of the event and determines the associated device or component to which the event relates, and takes the corresponding action for the event type and the associated action for the associated device or component as recommended actions. Specifically, taking the event type of the current event of AGV1 as an example of an industrial fieldbus error, FIG. 8 shows a schematic diagram of relationship-based action reasoning in the embodiment of FIG. 2. As shown in FIG. 8, a relationship-based action inference module 263 queries from the knowledge model of AGV1 that an event of the type of an industrial fieldbus error occurred on the industrial fieldbus that was linked to a tracking sensor whose parent component was a navigation component. The relationship-based action inference module 263 determines the tracking sensor and the parent component navigation component of the tracking sensor as associated components related to the industrial fieldbus error, and takes the action for the tracking sensor and the action for the navigation component as associated actions of the associated components. The relationship-based action inference module 263 takes actions for industrial fieldbus errors, actions for tracking sensors, and actions for navigation components as recommended actions. Likewise, the recommended actions may be ordered by priority index.

Where applicable, the event similarity identification module 261, the rule-based action query module 262, and the relationship-based action inference module 263 may be used simultaneously to generate recommended actions, respectively, for the same event type. After each sub-module generates a recommended action, the recommended actions are sorted according to the priority index and provided to the event processing module 25 as a final recommended action. The event processing module 25 saves the final recommended action in the event database 24.

Returning next to FIG. 3, in step 304, the field personnel perform maintenance on the field device and feedback on the recommended actions in accordance with the recommended actions. Specifically, field personnel obtain device data and recommended actions from event database 24 via the client device and maintain AGV1 according to the specific instrumentalities and personnel included in the recommended actions to handle the event that occurred. In step 305, the field personnel, after the maintenance is over, select an action actually taken from the recommended actions via the client device, or enter a new action actually taken without using the recommended action. The feedback data is stored in the event database 24 via the client device.

In step 306, the knowledge model is adjusted based on the feedback data. This step is performed by the model adaptation module 27 and the model generation module 21 in the system 200. The model adjustment module 27 takes feedback data on the recommended actions from the event database 24 and provides it to the model generation module 21 to augment and/or update the knowledge model. The model generation module 21 may add a priority index of the actions actually taken in the feedback data and/or add a new action and its relationship to the corresponding component and event type in the knowledge model.

Further, although specific modules are not shown in FIG. 2, the action recommendation module 26 may also periodically generate recommended actions for performing periodic maintenance on the field device based on the frequency of periodic maintenance actions in the knowledge model of the field device.

By establishing a knowledge model for each field device in the plant, maintenance knowledge of different knowledge sources of the field device can be integrated together, and device data of the field device can be analyzed by using the knowledge model, thereby accurately recommending maintenance suggestions for field personnel. The field personnel do not need to spend energy and time to learn the maintenance manuals of different field devices, and can utilize the maintenance knowledge of each knowledge source contained in the knowledge model to better understand the root cause of the fault and quickly and effectively maintain the field devices, so that the knowledge integration level and the transparency of the field devices are improved, and the accuracy and the efficiency of maintenance are ensured. Moreover, the knowledge models and the event data of all the field devices are stored in the unified database, so that a unified field device maintenance system can be realized in a factory, and the production and maintenance efficiency of the whole factory is improved. In addition, the knowledge model is easy to expand, and more intelligent and accurate recommendation can be realized along with the continuous expansion and accumulation of knowledge of the knowledge model.

FIG. 9 illustrates an apparatus for performing maintenance on field devices in a plant according to one embodiment of the present disclosure. Referring to fig. 9, the apparatus 900 includes a data acquisition unit 901, an action recommendation unit 902, and an action providing unit 903. The data acquisition unit 901 is configured to acquire device data of the field device, the device data representing an event currently occurring at the field device. The action recommendation unit 902 is configured to generate recommended actions for events based on the device data using a knowledge model of the field device, wherein the knowledge model comprises possible event types for the field device and corresponding actions for each event type. The action providing unit 903 is configured to provide recommended actions for maintenance of the field device. The units in fig. 9 may be implemented by software, hardware (e.g., integrated circuit, FPGA, etc.), or a combination of software and hardware.

In some embodiments, the action recommendation unit 903 is further configured to: inquiring corresponding actions of the event type in the knowledge model according to the event type of the event; and generating a recommended action based on the corresponding action.

In some embodiments, the knowledge model further includes associations of field devices and their components to other devices or components, and the action recommendation unit 903 is further configured to: determining an associated device or component related to the event based on the knowledge model; according to the event type of the event, inquiring the corresponding action of the event type and the associated action of the associated equipment or component in the knowledge model; and generating a recommended action based on the corresponding action and the associated action.

In some embodiments, the action recommendation unit 903 is further configured to: obtaining historical recommended actions for similar historical events, wherein the historical recommended actions were previously generated according to a knowledge model; and generating a recommended action based on the historical recommended action.

In some embodiments, the device data comprises status data of the field device, and the action recommendation unit is further configured to: determining a historical event of the same event type as the event; and selecting similar historical events from the historical events based on the status data.

In some embodiments, the apparatus 900 further comprises a feedback acquisition unit and a model adjustment unit (not shown in fig. 9). The feedback acquisition unit is configured to acquire feedback data for the recommended action, and the model adjustment unit is configured to adjust the knowledge model based on the feedback data.

In some embodiments, the model adjustment unit is further configured to: the corresponding action of the event type of the event is modified and/or the priority of the corresponding action is changed in the knowledge model.

In some embodiments, the apparatus 900 further comprises a knowledge acquisition unit and a model generation unit (not shown in fig. 9). The knowledge acquisition unit is configured to acquire knowledge source data related to the field device. The model generation unit is configured to generate a knowledge model of the field device based on the knowledge source data, wherein the knowledge source data includes at least one of: a maintenance manual for the field device, maintenance/repair records for the field device, and expert maintenance knowledge for the field device.

In some embodiments, the knowledge model of the field device is stored in a knowledge database, and the knowledge database further stores the knowledge model of at least one other field device in the plant.

FIG. 10 illustrates a block diagram of a computing device for performing maintenance on field devices in a plant in accordance with one embodiment of the present disclosure. As can be seen in fig. 10, a computing device 1000 for performing maintenance on field devices in a plant includes a processor 1001 and a memory 1002 coupled to the processor 1001. The memory 1002 is used to store computer-executable instructions that, when executed, cause the processor 1001 to perform the methods in the above embodiments.

Further, alternatively, the above-described method can be implemented by a computer-readable storage medium. Computer readable storage media has computer readable program instructions embodied thereon for performing the various embodiments of the disclosure. The computer readable storage medium may be a tangible device that can hold and store the instructions for use by the instruction execution device. The computer readable storage medium may be, for example, but not limited to, an electronic memory device, a magnetic memory device, an optical memory device, an electromagnetic memory device, a semiconductor memory device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium would include the following: a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a Static Random Access Memory (SRAM), a portable compact disc read-only memory (CD-ROM), a Digital Versatile Disc (DVD), a memory stick, a floppy disk, a mechanical coding device, such as punch cards or in-groove projection structures having instructions stored thereon, and any suitable combination of the foregoing. Computer-readable storage media as used herein is not to be construed as transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., optical pulses through a fiber optic cable), or electrical signals transmitted through electrical wires.

Thus, in another embodiment, the present disclosure proposes a computer-readable storage medium having stored thereon computer-executable instructions for performing the methods in the various embodiments of the present disclosure.

In another embodiment, the present disclosure proposes a computer program product that is tangibly stored on a computer-readable storage medium and includes computer-executable instructions that, when executed, cause at least one processor to perform the methods in the various embodiments of the present disclosure.

In general, the various example embodiments of this disclosure may be implemented in hardware or special purpose circuits, software, firmware, logic or any combination thereof. Certain aspects may be implemented in hardware, while other aspects may be implemented in firmware or software which may be executed by a controller, microprocessor or other computing device. While aspects of embodiments of the disclosure have been illustrated or described as block diagrams, flow charts, or using some other pictorial representation, it is well understood that the blocks, apparatus, systems, techniques or methods described herein may be implemented in, as non-limiting examples, hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof.

Computer-readable program instructions or computer program products for executing the embodiments of the present disclosure can also be stored in the cloud, and when a call is needed, a user can access the computer-readable program instructions stored in the cloud for executing one embodiment of the present disclosure through a mobile internet, a fixed network, or other networks, so as to implement the technical solutions disclosed according to the embodiments of the present disclosure.

While embodiments of the present disclosure have been described with reference to several particular embodiments, it should be understood that embodiments of the present disclosure are not limited to the particular embodiments disclosed. The embodiments of the disclosure are intended to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims. The scope of the claims is to be accorded the broadest interpretation so as to encompass all such modifications and equivalent structures and functions.

Claims

1. A method for performing maintenance on field devices in a plant, comprising:

obtaining device data of the field device, the device data representing a current occurrence of an event of the field device;

generating a recommended action for the event based on the device data with a knowledge model of the field device, wherein the knowledge model includes possible event types for the field device and a corresponding action for each event type; and

providing the recommended action to perform maintenance on the field device.

2. The method of claim 1, wherein generating, with a knowledge model of the field device, a recommended action for the event based on the device data further comprises:

inquiring corresponding actions of the event types in the knowledge model according to the event types of the events; and

generating the recommended action based on the corresponding action.

3. The method of claim 1, wherein the knowledge model further includes associations of the field device and its various components to other devices or components, and generating, with a pre-established knowledge model of the field device, recommended actions for the event based on the device data further comprises:

determining an associated device or component related to the event based on the knowledge model;

according to the event type of the event, inquiring the corresponding action of the event type and the associated action of the associated equipment or component in the knowledge model; and

generating the recommended action based on the corresponding action and the associated action.

4. The method of claim 1, wherein generating, with a knowledge model of the field device, a recommended action for the event based on the device data further comprises:

obtaining historical recommended actions for similar historical events, wherein the historical recommended actions were previously generated according to the knowledge model; and

generating the recommended action based on the historical recommended action.

5. The method of claim 4, wherein the device data includes status data of the field device, and further comprising:

determining a historical event of the same event type as the event; and

selecting the similar historical events from the historical events based on the status data.

6. The method of claim 1, further comprising:

acquiring feedback data of the recommended action; and

adjusting the knowledge model based on the feedback data.

7. The method of claim 6, wherein adjusting the knowledge model based on the feedback data further comprises:

modifying a corresponding action of an event type of the event and/or changing a priority of the corresponding action in the knowledge model.

8. The method of claim 1, further comprising:

obtaining knowledge source data related to the field device; and

generating a knowledge model of the field device based on the knowledge source data, wherein,

the source data of knowledge comprises at least one of: a maintenance manual for the field device, a maintenance/repair record for the field device, and expert maintenance knowledge for the field device.

9. The method of claim 1, wherein the knowledge model of the field device is maintained in a knowledge database, and wherein the knowledge database further maintains knowledge models of at least one other field device in the plant.

10. An apparatus for performing maintenance on field devices in a plant, comprising:

a data acquisition unit configured to acquire device data of the field device, the device data representing an event currently occurring with the field device;

an action recommendation unit configured to generate a recommended action for the event based on the field device data using a knowledge model of the field device, wherein the knowledge model includes possible event types for the field device and a corresponding action for each event type; and

an action providing unit configured to provide the recommended action to perform maintenance on the field device.

11. The apparatus of claim 10, wherein the action recommendation unit is further configured to:

generating the recommended action based on the corresponding action.

12. The apparatus of claim 10, wherein the knowledge model further includes associations of the field device and its various components to other devices or components, and the action recommendation unit is further configured to:

13. The apparatus of claim 10, wherein the action recommendation unit is further configured to:

generating the recommended action based on the historical recommended action.

14. The apparatus of claim 13, wherein the device data includes status data of the field device, and the action recommendation unit is further configured to:

determining a historical event of the same event type as the event; and

15. The apparatus of claim 10, further comprising:

a feedback acquisition unit configured to acquire feedback data on the recommended action; and

a model adjustment unit configured to adjust the knowledge model based on the feedback data.

16. The apparatus of claim 15, wherein the model adjustment unit is further configured to:

17. A computing device, comprising:

a processor; and

a memory for storing computer-executable instructions that, when executed, cause the processor to perform the method of any of claims 1-9.

18. A computer-readable storage medium having computer-executable instructions stored thereon for performing the method of any one of claims 1-9.

19. A computer program product, tangibly stored on a computer-readable storage medium, and comprising computer-executable instructions that, when executed, cause at least one processor to perform the method of any one of claims 1-9.