JP7529560B2 - Fault diagnosis device, fault diagnosis system, and fault diagnosis program - Google Patents

Description

The present invention relates to a fault diagnosis device, a fault diagnosis system, and a fault diagnosis program, and more particularly to a fault diagnosis device, a fault diagnosis system, and a fault diagnosis program for diagnosing faults in a fuel cell cogeneration system.

In some conventional equipment fault diagnosis systems, when there is a gap in the operation data acquired by the operation data acquisition means, the missing data portion is complemented with complementary data complemented by the missing data complementation means, and then an analysis is performed according to the fault diagnosis rules using the fault diagnosis means (see, for example, Patent Document 1).

JP 2005-309616 A

According to the technology described in Patent Document 1, even if the data required for diagnosis is missing, existing fault diagnosis rules can be applied as is without modification to perform diagnosis. However, the technology described in Patent Document 1 is intended for facility equipment such as air conditioners, and is not intended for fuel cell systems.

When using a fault diagnosis system to identify faulty parts from operating data in the maintenance of a fuel cell system, the performance of the initially created fault diagnosis model may deteriorate due to factors such as changes in the shape of the parts or changes in control. Furthermore, if the number of faults occurring in the relevant parts is small, it may not be possible to fully verify the performance when the model is created. For this reason, it is desirable to monitor the performance of the fault diagnosis model and update the model as necessary to maintain the model performance at a certain level or above. A certain level here means, for example, a level that can fully guarantee the performance of a fuel cell cogeneration system. However, this does not mean that the system performance cannot be guaranteed if even one faulty part is overlooked, but rather it is sufficient to ensure that maintenance operations are not hindered.

The present invention has been made in consideration of the above circumstances, and aims to provide a fault diagnosis device, a fault diagnosis system, and a fault diagnosis program that can maintain the performance of a fault diagnosis model used in fault diagnosis of a fuel cell cogeneration system at a certain level or higher.

In order to achieve the above object, a fault diagnosis device according to one aspect of the present invention includes: an acquisition unit that acquires, when the fuel cell cogeneration system detects an operational abnormality, from the fuel cell cogeneration system, operation history data related to the operation history of the fuel cell cogeneration system that corresponds to the abnormality; an estimation unit that inputs the operation history data acquired by the acquisition unit or data obtained by processing the operation history data into a fault diagnosis model that is generated by associating a group of previously acquired operation history data with the functional units of the fuel cell cogeneration system and performing machine learning or multivariate analysis, and that judges the presence or absence of a fault for each functional unit of the fuel cell cogeneration system, and estimates the presence or absence of a fault for each functional unit of the fuel cell cogeneration system using the judgment result output from the fault diagnosis model; and a learning unit that generates a new fault diagnosis model by relearning the fault diagnosis model when the fault diagnosis model satisfies a predetermined condition.

In addition, a fault diagnosis system according to one aspect of the present invention includes a fuel cell cogeneration system and a fault diagnosis device connected to the fuel cell cogeneration system. When the fuel cell cogeneration system detects an abnormality in the operation of the system, the system transmits operation history data related to the operation history of the system corresponding to the abnormality to the fault diagnosis device. The fault diagnosis device includes an acquisition unit that acquires the operation history data transmitted from the fuel cell cogeneration system, an estimation unit that inputs the operation history data acquired by the acquisition unit or data obtained by processing the operation history data into a fault diagnosis model that is generated by associating a group of previously acquired operation history data with the functional units of the fuel cell cogeneration system and performing machine learning or multivariate analysis, and that determines whether or not there is a fault for each functional unit of the fuel cell cogeneration system, and estimates the presence or absence of a fault for each functional unit of the fuel cell cogeneration system using the judgment result output from the fault diagnosis model, and a learning unit that generates a new fault diagnosis model by relearning the fault diagnosis model when the fault diagnosis model satisfies a predetermined condition.

In addition, a fault diagnosis program according to one aspect of the present invention causes a computer to function as each component of the fault diagnosis device.

As described above in detail, according to the present invention, the performance of the fault diagnosis model used for fault diagnosis of a fuel cell cogeneration system can be maintained at a certain level or higher.

1 is a diagram illustrating an example of a configuration of a fault diagnosis system according to a first embodiment. FIG. 2 is a block diagram showing an example of a configuration of a CGS according to the first embodiment. 5 is a flowchart showing an example of a process flow according to a control program according to the first embodiment. 1 is a block diagram showing an example of an electrical configuration of a fault diagnosis device according to a first embodiment; 1 is a block diagram showing an example of a functional configuration of a fault diagnosis device according to a first embodiment; 4 is a flowchart showing an example of a processing flow of a fault diagnosis program according to the first embodiment. 5 is a flowchart showing an example of a flow of a learning process by the fault diagnosis program according to the first embodiment. 5 is a flowchart showing an example of a flow of a model updating process by the fault diagnosis program according to the first embodiment. 11A and 11B are diagrams illustrating precision and recall rates according to an embodiment. FIG. 1 is a diagram for explaining the concept of the PRAUC method according to an embodiment. 10 is a flowchart showing an example of a flow of a model updating process by a fault diagnosis program according to a second embodiment. 13 is a flowchart showing an example of the flow of a model updating process by a fault diagnosis program according to a third embodiment. 13 is a flowchart showing an example of the flow of a model updating process by a fault diagnosis program according to a fourth embodiment.

Below, an example of a form for implementing the present invention will be described in detail with reference to the drawings.

[First embodiment]
FIG. 1 is a diagram showing an example of the configuration of a fault diagnosis system 100 according to the first embodiment.

As shown in FIG. 1, the fault diagnosis system 100 according to this embodiment includes a fuel cell cogeneration system (hereinafter simply referred to as "CGS") 40, a fault diagnosis device 10, and a maintenance terminal 70. The fault diagnosis system 100 is configured as a system for diagnosing faults in the CGS 40.

The CGS 40 is, for example, an ENE-FARM (registered trademark) and is installed in the user's home 30. The fault diagnosis device 10 is a device for diagnosing faults in the CGS 40 and is connected to the CGS 40 via a network N. The fault diagnosis device 10 may be, for example, a general-purpose computer device such as a server computer or a personal computer (PC). The network N may be, for example, a network such as a LAN (Local Area Network), a WAN (Wide Area Network), or the Internet.

The maintenance terminal 70 is a terminal owned by the worker 60 who performs maintenance work on the CGS 40. The maintenance terminal 70 is connected to the fault diagnosis device 10 via the network N. The maintenance terminal 70 may be, for example, a portable tablet terminal, a smartphone, or a notebook PC.

When the CGS 40 detects an operational abnormality (hereinafter referred to as an "error"), the fault diagnosis device 10 according to this embodiment inputs the operation history data at the time the error was detected into the fault diagnosis model to perform fault diagnosis.

Specifically, in FIG. 1, when CGS 40 detects an error, it issues an error report. At this time, CGS 40 automatically transmits operation history data of its own system to the fault diagnosis device 10. The operation history data is, for example, data relating to at least one operation history at the time of error detection, for a few seconds (e.g., 10 seconds or less) before the error is detected, and for a few seconds (e.g., 10 seconds or less) after the error is detected. The operation history data includes, for example, detection values of various sensors, data indicating the operating status of auxiliary equipment (e.g., valves, pumps, etc.), error codes, etc.

The fault diagnosis device 10 stores in advance in the storage unit a fault diagnosis model for each of the multiple functional units of the CGS 40. The fault diagnosis model is a mathematical model for diagnosing a fault for each functional unit of the CGS 40. The functional unit includes at least one part (e.g., a pump, a valve, a pipe, a tank, etc.). The fault diagnosis model of the CGS 40 is a model generated by machine learning by associating a group of operation history data obtained in the past with the functional unit. Examples of machine learning include random forests, neural networks, and support vector machines. Note that multivariate analysis may be applied to the fault diagnosis model. Examples of multivariate analysis include logistic regression. For example, two-class classification or multi-class classification is used for the fault diagnosis model to determine the presence or absence of a fault for each functional unit. The fault diagnosis device 10 processes the operation history data acquired from the CGS 40 as is, or processes it into data that can be input to the fault diagnosis model, and inputs the processed data to each of the fault diagnosis models. Each fault diagnosis model outputs, for example, "fault present (fault)" or "no fault present (healthy)" for each functional unit. Specifically, when the index value indicated by the data is equal to or greater than a threshold, "fault present" is output, and when the index value indicated by the data is less than the threshold, "no fault present" is output. The fault diagnosis device 10 uses the judgment results output from each fault diagnosis model to estimate the presence or absence of a fault for each functional unit, and retains the diagnosis results of the fault diagnosis obtained by the estimation.

The worker (maintenance staff) 60 accesses the fault diagnosis device 10 from the maintenance terminal 70 and checks the fault location indicated by the diagnosis results. The worker 60 then performs part replacement work etc. on-site based on the diagnosis results obtained from the fault diagnosis device 10.

Figure 2 is a block diagram showing an example of the configuration of CGS 40 according to the first embodiment.

As shown in FIG. 2, the CGS 40 according to this embodiment is broadly divided into a control device 41 and a CGS main body 49. The control device 41 may be configured integrally with the CGS main body 49, or may be configured separately from the CGS main body 49.

The control device 41 functions as a controller for the CGS 40. The control device 41 includes a CPU (Central Processing Unit) 42, a ROM (Read Only Memory) 43, a RAM (Random Access Memory) 44, an input/output interface (I/O) 45, a storage unit 46, a communication unit 47, and a device interface (hereinafter referred to as "device I/F") 48.

The CPU 42, ROM 43, RAM 44, and I/O 45 are each connected via a bus. Functional units including a memory unit 46, a communication unit 47, and a device I/F 48 are connected to the I/O 45. These functional units are capable of communicating with the CPU 42 via the I/O 45.

For example, a hard disk drive (HDD), a solid state drive (SSD), a flash memory, or the like is used as the storage unit 46. A control program 46A for controlling the operation of the CGS main body unit 49 is stored in the storage unit 46. Note that this control program 46A may be stored in the ROM 43.

The control program 46A may be pre-installed in the control device 41, for example. The control program 46A may be realized by storing it in a non-volatile storage medium or distributing it via the network N and installing it appropriately in the control device 41. Examples of non-volatile storage media include a CD-ROM (Compact Disc Read Only Memory), a magneto-optical disk, a HDD, a DVD-ROM (Digital Versatile Disc Read Only Memory), a flash memory, a memory card, etc.

The communication unit 47 is connected to a network N such as the Internet, a LAN, or a WAN, and is capable of communicating with an external fault diagnosis device 10 via the network N.

The CGS main body 49 is connected to the device I/F 48. That is, the various electrical components included in the CGS main body 49 are connected to the CPU 42 via the device I/F 48 so as to be able to communicate with each other.

The CGS main body 49 has a known configuration. Specifically, the CGS main body 49 includes a fuel cell unit 50. The fuel cell unit 50 includes a fuel cell module 51, a gas path 52 connected to the fuel cell module 51, a reforming water path 53, and an air path 54. As described above, the CGS main body 49 includes a plurality of functional parts. This functional part includes at least one component. For example, this functional part may be a plurality of components constituting the gas path 52, a plurality of components constituting the reforming water path 53, or a plurality of components constituting the air path 54. This functional part may be an individual component constituting the CGS main body 49. This component may include, for example, a pump, a valve, a pipe, a tank, etc.

The fuel cell module 51 includes a fuel cell stack 51A and a reformer 51B. The reformer 51B reforms a gas containing a hydrocarbon raw material (e.g., city gas). The fuel cell stack 51A is a stack of multiple fuel cell units each having an electrolyte layer, a fuel electrode, and an air electrode. The fuel cell stack 51A is configured to generate electricity and water by reacting hydrogen in the reformed gas reformed from city gas by the reformer 51B with oxygen in the air. The fuel cell unit 50 includes auxiliary equipment such as a valve and a pump for adjusting the supply amount of the reformed gas and air, and a heat exchanger for exchanging heat generated by the power generation by the fuel cell stack 51A with a heat transfer medium (e.g., water, etc.).

The CGS main body 49 is equipped with a hot water storage tank. In the CGS main body 49, when water is supplied to the hot water storage tank, the water is supplied from the hot water storage tank to the heat exchanger of the fuel cell unit 50, where it is heated by the heat of the fuel cell stack 51A. When the water is heated in the heat exchanger, it becomes hot water. This hot water is supplied to the hot water storage tank and stored in the hot water storage tank. The hot water storage tank is equipped with auxiliary equipment such as a valve and pump for moving water and hot water back and forth between the fuel cell unit 50 and the hot water storage tank, and a valve and pump for draining the hot water stored in the hot water storage tank.

The gas path 52 is a path through which city gas flows. The gas path 52 includes auxiliary equipment such as a valve and a pump for adjusting the amount of city gas supplied. The reforming water path 53 is a path through which reforming water flows. The reforming water path 53 includes auxiliary equipment such as a valve and a pump for adjusting the amount of reforming water supplied. The air path 54 is a path through which air flows. The air path 54 includes auxiliary equipment such as a valve and a pump for adjusting the amount of air supplied.

The control device 41 is a controller that controls the auxiliary devices provided in the CGS main body 49. The control device 41 outputs control signals to the CGS main body 49 for controlling the auxiliary devices. The CGS main body 49 also outputs operation data representing the operation status of the CGS main body 49 to the control device 41. This operation data includes, as feature values, data representing the operating state of the auxiliary devices (e.g., voltage value, current value, etc.), detection values of various sensors provided in the CGS main body 49, etc. Specifically, the data representing the operating state of the auxiliary devices is, for example, data representing the operation amount of the pump in the case of a pump, and data representing the open/closed state of the valve in the case of a valve. Also, the detection values of various sensors are, for example, values representing the flow rates of the city gas, reformed water, and air in the case of piping, and values representing the water level in the case of a tank.

The control device 41 stores the time-series operation data acquired from the CGS main body 49 in the memory unit 46. The control device 41 has a function of detecting an error in the CGS main body 49 based on the operation data acquired from the CGS main body 49. Note that the error is detected, for example, by comparing a feature obtained from the operation data with a corresponding threshold value.

Now, referring to FIG. 3, the error reporting process by the control device 41 according to this embodiment will be specifically described. Note that this error reporting process is executed by the control program 46A included in the control device 41.

Figure 3 is a flowchart showing an example of the processing flow of control program 46A according to the first embodiment.

First, the CPU 42 starts the control program 46A stored in the memory unit 46, and executes the steps shown below.

In step S101 in FIG. 3, the CPU 42 stores the operation data acquired in chronological order from the CGS main body 49 in the memory unit 46, and determines whether or not an abnormal value indicating the occurrence of an error has been detected based on the acquired operation data. If it is determined that an abnormal value has been detected (if a positive determination), the process proceeds to step S102, and if it is determined that no abnormal value has been detected (if a negative determination), the process waits in step S101.

In step S102, the CPU 42 extracts at least one piece of driving data from the time-series driving data stored in the memory unit 46, the driving data being at the time of error detection, a few seconds (e.g., 10 seconds or less) before the error detection, and a few seconds (e.g., 10 seconds or less) after the error detection, as operation history data, and stores the extracted operation history data in the memory unit 46. As described above, this operation history data includes, for example, detection values of various sensors, data indicating the operating status of auxiliary equipment, error codes, etc. The operation history data stored in the memory unit 46 is referred to as "data 1".

In step S103, the CPU 42 determines that an error occurred due to the retention of data 1 in step S102.

In step S104, the CPU 42 transmits the data 1 held in step S102 to the fault diagnosis device 10 via the communication unit 47, and ends the series of processes performed by this control program 46A.

Figure 4 is a block diagram showing an example of the electrical configuration of the fault diagnosis device 10 according to the first embodiment.

As shown in FIG. 4, the fault diagnosis device 10 according to this embodiment includes a CPU 11, a ROM 12, a RAM 13, an I/O 14, a memory unit 15, a display unit 16, an operation unit 17, and a communication unit 18.

The CPU 11, ROM 12, RAM 13, and I/O 14 are each connected via a bus. The I/O 14 is connected to various functional units including a memory unit 15, a display unit 16, an operation unit 17, and a communication unit 18. These functional units are capable of communicating with the CPU 11 via the I/O 14.

For example, a HDD, SSD, flash memory, etc., is used as the storage unit 15. A fault diagnosis program 15A for diagnosing faults in the CGS 40 is stored in the storage unit 15. Note that this fault diagnosis program 15A may be stored in the ROM 12.

The fault diagnosis program 15A may be pre-installed in the fault diagnosis device 10, for example. The fault diagnosis program 15A may be realized by storing it in a non-volatile storage medium or distributing it via the network N and installing it appropriately in the fault diagnosis device 10. Examples of non-volatile storage media include CD-ROMs, optical magnetic disks, HDDs, DVD-ROMs, flash memories, memory cards, etc.

The display unit 16 may be, for example, a liquid crystal display (LCD) or an organic electroluminescence (EL) display. The display unit 16 may have an integrated touch panel. The operation unit 17 is provided with devices for operation input, such as a keyboard and a mouse. The display unit 16 and the operation unit 17 receive various instructions from a user of the fault diagnosis device 10. The display unit 16 displays various information, such as the results of processing executed in response to instructions received from the user and notifications regarding processing.

The communication unit 18 is connected to a network N such as the Internet, a LAN, or a WAN, and is capable of communicating with the CGS 40 and the maintenance terminal 70 via the network N.

The CPU 11 of the fault diagnosis device 10 according to this embodiment writes the fault diagnosis program 15A stored in the memory unit 15 to the RAM 13 and executes it, thereby functioning as each unit shown in FIG. 5.

Figure 5 is a block diagram showing an example of the functional configuration of the fault diagnosis device 10 according to the first embodiment.

As shown in FIG. 5, the CPU 11 of the fault diagnosis device 10 according to this embodiment functions as an acquisition unit 11A, an estimation unit 11B, a learning unit 11C, a first output unit 11D, and a second output unit 11E.

As described above, the memory unit 15 prestores a fault diagnosis model 15B for each functional unit. That is, one fault diagnosis model 15B corresponds to one functional unit (or part). As described above, the fault diagnosis model 15B is a mathematical model for diagnosing faults for each functional unit of the CGS 40, which is obtained, for example, by machine learning.

The acquisition unit 11A acquires the operation history data transmitted from the above-mentioned CGS 40. For example, data 1 is acquired as the operation history data.

The estimation unit 11B processes the operation history data acquired by the acquisition unit 11A into data that can be input to the fault diagnosis model 15B, and inputs the processed data to the fault diagnosis model 15B. The operation history data may be input to the fault diagnosis model 15B as is without processing it. The estimation unit 11B then estimates the presence or absence of a fault for each functional part of the CGS 40 using the judgment result output from the fault diagnosis model 15B. The fault diagnosis model 15B may be a model that performs two-class classification that outputs a fault or sound as the judgment result, or a model that performs three-class classification that outputs a fault, sound, or suspected fault as the judgment result.

The learning unit 11C generates a fault diagnosis model 15B by performing machine learning using a group of operation history data obtained in the past as learning data. The fault diagnosis model 15B generated by the learning unit 11C is stored in the memory unit 15. Note that the storage location of the fault diagnosis model 15B is not limited to the memory unit 15. For example, it may be stored in an external storage device. Also, in this embodiment, the device is configured to perform machine learning on its own, but it may also be configured to perform machine learning on an external device. Also, instead of machine learning, the fault diagnosis model 15B may be generated using multivariate analysis.

The first output unit 11D outputs and stores the final diagnosis result for each functional part estimated by the estimation unit 11B, for example, in the storage unit 15. In addition, the first output unit 11D transmits the final diagnosis result stored in the storage unit 15 to the maintenance terminal 70 in response to an access from the maintenance terminal 70. The final diagnosis result includes the diagnosis result (failure, soundness, suspected failure) and the action to be taken for each functional part (or each part). For example, if the judgment result of data 1 is "failure", the action to be taken by the worker 60 is "part replacement". In addition, if the judgment result of data 1 is "suspected failure", the action to be taken by the worker 60 is "part operation check". In addition, if the judgment result of data 1 is "sound", the action to be taken by the worker 60 is "none". In addition, the second output unit 11E outputs and stores the fault diagnosis model 15B generated by the learning unit 11C, for example, in the storage unit 15.

Next, the operation of the fault diagnosis device 10 according to the first embodiment will be described with reference to FIG.

Figure 6 is a flowchart showing an example of the processing flow of the fault diagnosis program 15A according to the first embodiment. Note that in this embodiment, the functional unit is represented as a single component.

First, the CPU 11 starts the fault diagnosis program 15A stored in the memory unit 15, and executes the steps shown below.

In step S111 of FIG. 6, the CPU 11 acquires the operation history data (here, data 1) transmitted from the control device 41 of the CGS 40.

In step S112, the CPU 11 processes the data 1 acquired in step S111 into data that can be input to the fault diagnosis model 15B for each functional unit (each component in this case). Processing here means deleting part of the data, extracting part of the data, adding new data, etc. to the data 1. Processing also includes converting the data format of the data 1 into a format suitable for each fault diagnosis model. Note that processing is omitted when the operation history data is used as is.

In step S113, the CPU 11 inputs the data 1 processed in step S112 into the fault diagnosis model 15B.

In step S114, the CPU 11 stores the judgment result output from the fault diagnosis model 15B in the memory unit 15.

In step S115, the CPU 11 judges whether or not the judgment results for all parts have been stored in the memory unit 15. If it is judged that the judgment results for all parts have been stored in the memory unit 15 (if a positive judgment), the process proceeds to step S116. If it is judged that the judgment results for all parts have not been stored in the memory unit 15 (if a negative judgment), the process returns to step S113 and the process is repeated; that is, data 1 is input to the fault diagnosis model 15B for part A, the fault diagnosis model 15B for part B, the fault diagnosis model 15B for part C, ..., and the process of obtaining judgment results for parts A, B, C, ... is repeated.

In step S116, the CPU 11 outputs the final diagnosis result obtained from the judgment results of the fault diagnosis model 15B for all parts held in step S115, for example to the storage unit 15, and ends the series of processes by the fault diagnosis program 15A. In this embodiment, the fault diagnosis process for data 1 is repeated the number of times corresponding to the number of predetermined functional units.

Next, the learning process performed by the fault diagnosis device 10 according to the first embodiment will be described in detail with reference to FIG. 7.

Figure 7 is a flowchart showing an example of the flow of the learning process by the fault diagnosis program 15A according to the first embodiment.

First, the CPU 11 starts the fault diagnosis program 15A stored in the memory unit 15, and executes the steps shown below.

In step S121 of FIG. 7, the CPU 11 acquires past operation history data as learning data.

In step S122, the CPU 11 processes the operation history data acquired as learning data in step S121 into data that can be input to the learning model. Note that processing is omitted if the operation history data is to be used as is.

In step S123, the CPU 11 inputs the data obtained by processing in step S122 together with correct answer data (e.g., faulty, healthy, suspected fault) to create a fault diagnosis model for each functional part. In the process of creating the fault diagnosis model 15B, learning is performed using an algorithm such as a support vector machine, random forest, or neural network to create a fault diagnosis model 15B that determines whether a specific functional part (e.g., a part) is faulty, healthy, or suspected to be faulty. Note that the parameters of each algorithm are also optimized in this step.

In step S124, the CPU 11 determines whether the predetermined machine learning has been completed. If it is determined that the predetermined machine learning has been completed (if the result is positive), the process proceeds to step S125, and if it is determined that the predetermined machine learning has not been completed (if the result is negative), the process returns to step S121 and is repeated.

In step S125, the CPU 11 stores the trained model generated by machine learning in the memory unit 15 as the fault diagnosis model 15B, and ends the series of processes performed by the fault diagnosis program 15A.

Here, the fault diagnosis device 10 according to this embodiment has a function of generating a new fault diagnosis model by re-learning the fault diagnosis model when the fault diagnosis model 15B satisfies a predetermined condition. Specifically, this function is executed by the learning unit 11C. The predetermined condition includes, for example, at least one of the following conditions: the performance of the fault diagnosis model 15B does not reach a certain level; the performance of the fault diagnosis model 15B deteriorates over time; the number of data items for which fault diagnosis has been performed by the fault diagnosis model 15B exceeds a certain value; and the period for which fault diagnosis has been performed by the fault diagnosis model 15B exceeds a certain period.

In this embodiment, the predetermined condition is that the performance of the fault diagnosis model 15B does not reach a certain level.

When the performance of the fault diagnosis model 15B does not reach a certain level, the learning unit 11C generates a new fault diagnosis model using a group of past operation history data used for fault diagnosis as learning data. For example, at least one of the precision rate at the time of fault judgment and the recall rate of fault detection is used as an index representing the performance here. Then, when the generalization performance of the new fault diagnosis model is equal to or higher than a certain level, the learning unit 11C updates the fault diagnosis model 15B to the new fault diagnosis model. The generalization performance here means performance for unknown data. Examples of methods for evaluating the generalization performance include well-known methods such as the hold-out method and the k-cross validation method. Also, as in the above, for example, at least one of the precision rate at the time of fault judgment and the recall rate of fault detection is used as an index representing the generalization performance.

In addition, the learning unit 11C discards the fault diagnosis model 15B and the new fault diagnosis model if the generalization performance of the new fault diagnosis model is below a certain level.

In other words, in this embodiment, the performance of the fault diagnosis model 15B (e.g., precision rate, recall rate, etc.) is monitored to confirm that the fault diagnosis model 15B has versatility equal to or greater than a certain level. If the performance of the fault diagnosis model 15B does not reach the certain level, re-learning of the fault diagnosis model 15B is performed. If the generalization performance of the new fault diagnosis model obtained by the re-learning for past data is equal to or greater than a certain level, the new model is updated to, that is, the new model is adopted and deployed. If the generalization performance of the new model is less than a certain level, no fault diagnosis model that meets the certain level exists, and therefore the part is excluded from the target of the fault diagnosis system.

Next, the model update process performed by the fault diagnosis device 10 according to the first embodiment will be described in detail with reference to FIG.

Figure 8 is a flowchart showing an example of the flow of the model update process by the fault diagnosis program 15A according to the first embodiment.

First, the CPU 11 starts the fault diagnosis program 15A stored in the memory unit 15, and executes the steps shown below. In this embodiment, if the performance of the fault diagnosis model 15B does not reach a certain level, the fault diagnosis model 15B is re-learned.

In step S131 of FIG. 8, the CPU 11 acquires the diagnosis result (e.g., faulty or healthy) of the fault diagnosis model 15B (current fault diagnosis model) for an arbitrary part, and transmits the acquired diagnosis result to the maintenance terminal 70. Then, if the diagnosis result is a fault, the worker 60 who owns the maintenance terminal 70 performs fault diagnosis work on the target part at the site and checks whether the target part is faulty or healthy. Then, the worker 60 inputs the confirmation result of whether the target part is faulty or healthy via the maintenance terminal 70.

In step S132, the CPU 11 accepts input of the confirmation results of the failure or soundness of the target part from the worker 60 via the maintenance terminal 70.

In step S133, the CPU 11 stores in the memory unit 15 a set of the operation history data used to diagnose the fault of the target part and the verification results of the target part.

In step S134, the CPU 11 updates the performance of the fault diagnosis model 15B using the operation history data and confirmation results stored in the memory unit 15 in step S133.

In step S135, the CPU 11 determines whether the performance of the fault diagnosis model 15B, whose performance was updated in step S134, has not yet reached a certain level. If it is determined that the performance of the fault diagnosis model 15B has not yet reached a certain level (if the determination is positive), the process proceeds to step S136. If it is determined that the performance of the fault diagnosis model 15B has not yet reached a certain level, that is, has reached a certain level (if the determination is negative), the process returns to step S131 and is repeated.

Here, the fault diagnosis device 10 has a function of monitoring the performance of the fault diagnosis model 15B. As described above, the index representing the performance of the fault diagnosis model 15B may be, for example, at least one of the accuracy rate at the time of fault determination and the recall rate of fault detection.

The above-mentioned precision rate and recall rate will be explained in detail with reference to Figure 9.

Figure 9 is a diagram used to explain the precision rate and recall rate according to this embodiment.

The table in Figure 9 shows the correspondence between predictions and actual conditions for the fault diagnosis model of part A. The number of data points is shown within the box. In other words, the number of data points when the prediction is correct and the actual condition is correct is 28 (=A). The number of data points when the prediction is faulty and the actual condition is correct is 1 (=B). The number of data points when the prediction is correct and the actual condition is faulty is 12 (=C). The number of data points when the prediction is faulty and the actual condition is faulty is 9 (=D).

In the example of Figure 9, the accuracy rate at the time of fault determination = D/(B+D) = 9/10 = 90%. In other words, in this case, the accuracy rate is the ratio of the number of data items that were actually faulty to the total number of data items that were predicted to be faulty.

The recall rate of fault detection indicates the rate at which faults are found, and in the example of Figure 9, it is expressed as recall rate = D/(C+D). In other words, the recall rate is the ratio of the number of data items predicted to be faulty to the total number of data items that were actually faulty.

The matching rate at the time of the healthy judgment may also be used. In the example of FIG. 9, the matching rate at the time of the healthy judgment is expressed as A/(A+C). That is, in this case, the matching rate is the ratio of the number of data that was actually healthy to the total number of data predicted to be healthy. Note that when the matching rate at the time of the healthy judgment is used, even if the diagnosis result by the fault diagnosis model 15B is healthy, the worker 60 goes to the site to confirm whether the target part is actually faulty or healthy, and inputs the confirmation result via the maintenance terminal 70.

The performance index of the fault diagnosis model 15B may be an accuracy rate. The accuracy rate is the ratio of the number of correct data to the total number of predicted data.

In the above, the higher the matching rate is in the range of 0 to 1, the higher the model performance is. In this case, if the matching rate is equal to or higher than a threshold, it is determined that the performance of the fault diagnosis model 15B has reached a certain level. In addition, the higher the recall rate is in the range of 0 to 1, the higher the model performance is. In this case, if the recall rate is equal to or higher than a threshold, it is determined that the performance of the fault diagnosis model 15B has reached a certain level. In addition, the higher the accuracy rate is in the range of 0 to 1, the higher the model performance is. In this case, if the accuracy rate is equal to or higher than a threshold, it is determined that the performance of the fault diagnosis model 15B has reached a certain level.

Also, both the precision rate and the recall rate may be used. Specifically, as an example, the PRAUC (Precision Recall Area Under Curve) method shown in FIG. 10 may be applied to evaluate the performance of the fault diagnosis model 15B.

Figure 10 is a diagram to explain the concept of the PRAUC method according to this embodiment.

In FIG. 10, the vertical axis indicates the precision at the time of fault judgment, and the horizontal axis indicates the recall of fault detection. The recall and precision are plotted when the threshold for judging the fault/soundness of the fault diagnosis model 15B is changed, and a PR curve is created. The area of the area under the PR curve is called the AUC (Area Under Curve). In the PRAUC method, the larger the area AUC is in the range of 0 to 1, the higher the model performance is. In other words, the PR curve when the area AUC is 1 is considered to be an ideal PR curve. For example, if the precision or recall at any operating point (threshold) is equal to or greater than a preset value required for maintenance operations, it is determined that the performance of the fault diagnosis model 15B has reached a certain level. Note that the set value of the precision and the set value of the recall are different.

Returning to FIG. 8, in step S136, the CPU 11 re-learns the fault diagnosis model 15B to generate a new fault diagnosis model. The learning data used for re-learning is a set of past operation history data and its correct answer data used in fault diagnosis by the fault diagnosis model 15B.

In step S137, the CPU 11 judges whether the generalization performance of the new fault diagnosis model generated in step S136 is equal to or higher than a certain level with respect to past data. If it is judged that the generalization performance of the new fault diagnosis model is equal to or higher than a certain level with respect to past data (if the judgment is positive), the process proceeds to step S138, and if it is judged that the generalization performance of the new fault diagnosis model is lower than a certain level with respect to past data (if the judgment is negative), the process proceeds to step S139.

In step S138, the CPU 11 updates the fault diagnosis model 15B to the new fault diagnosis model generated in step S136, that is, adopts and deploys the new model, and ends the series of processes performed by this fault diagnosis program 15A.

On the other hand, in step S139, the CPU 11 discards the fault diagnosis model 15B, which is the current fault diagnosis model.

In step S140, the CPU 11 discards the new fault diagnosis model generated in step S136.

In step S141, since there is no fault diagnosis model that meets a certain standard for the target part, the CPU 11 sets the target part as outside the scope of the fault diagnosis system, and ends the series of processes by this fault diagnosis program 15A.

In the present embodiment, the fault diagnosis device 10 is implemented as an external server device, but this is not limiting. The fault diagnosis device 10 may also be implemented as the control device 41 of the CGS 40.

In this manner, according to this embodiment, if the performance of the fault diagnosis model used to diagnose faults in a fuel cell cogeneration system does not reach a certain level, the fault diagnosis model can be re-learned and updated. This makes it possible to maintain the performance of the fault diagnosis model at or above a certain level.

Second Embodiment
In the second embodiment, a configuration will be described in which a fault diagnosis model is re-learned when the performance of the fault diagnosis model deteriorates over time.

The fault diagnosis device according to the second embodiment has the same components as the fault diagnosis device 10 according to the first embodiment, and will therefore be described with reference to FIG. 5 above.

In this embodiment, the predetermined condition is that the performance of the fault diagnosis model 15B deteriorates over time. Normally, fuel cell systems, even if they are the same model, often undergo running changes in hardware and control, and can be said to be devices that are prone to losing the generalization performance of the fault diagnosis model over time.

When the performance of the fault diagnosis model 15B deteriorates over time, the learning unit 11C generates a new fault diagnosis model using the most recent operation history data group used for fault diagnosis as learning data. Note that the most recent data is, for example, a certain number of recent data, data for a certain period of time, or data after the starting point of performance deterioration (when the slope of performance deterioration is at least a certain level). Then, when the generalization performance of the new fault diagnosis model is at or above a certain level, the learning unit 11C updates the fault diagnosis model 15B to the new fault diagnosis model. Note that when the number of most recent data is sufficient for learning and verification, re-learning and generalization performance evaluation may be performed using only the most recent data.

When the generalization performance of the new fault diagnosis model is below a certain level, the learning unit 11C weights the most recent operation history data group and generates a second new fault diagnosis model using the weighted most recent operation history data group as learning data. When the generalization performance of the second new fault diagnosis model is equal to or higher than a certain level, the learning unit 11C updates the fault diagnosis model 15B to the second new fault diagnosis model. As a specific method of weighting, for example, method A and method B are considered in which data 1, 2, 3, ..., N (most recent) are arranged in chronological order and the data number is used as the weight. For example, when the target of evaluation is the conformance rate, in the conventional method, conformance rate = number of actual faults in the fault judgment / number of fault judgments, where the weight of each data is 1. In contrast, in method A, it is as follows.

Compliance rate = Σ{(Fault judged to be actual fault x data number n) / (Fault judgement x data number n)}, where the weights increase proportionally. "Fault judged to be actual fault" and "Fault judgement" are data of 0 or 1.

And in method B, it will look like this:

Conformity rate = Σ{(coefficient C(n) x actual failure in failure judgment x data number n) / (coefficient C(n) x failure judgment x data number n)}, where coefficient C(n) is a coefficient for adjusting the weight of the most recent data in a non-proportional manner. Coefficient C(n) is a function of data number n, and can be either a continuous function or a discontinuous function (such as a step function). "Actual failure in failure judgment" and "Failure judgment" are data of 0 or 1.

In addition, the learning unit 11C discards the fault diagnosis model 15B, the new fault diagnosis model, and the second new fault diagnosis model if the generalization performance of the second new fault diagnosis model is below a certain level.

In other words, in this embodiment, the performance (e.g., precision, recall, etc.) of the fault diagnosis model 15B is monitored over time (e.g., time-number of data), and if significant performance degradation is observed for a certain number of data or for a certain period of time, re-learning is performed. Note that in this embodiment, since chronological performance degradation is the cause of re-learning, it is desirable to use the most recent data as test data (used to evaluate the model's performance) during re-learning. Furthermore, if performance is not achieved even after re-learning, modeling that is more suited to the most recent data can be performed by weighting the most recent data. If performance is still not sufficient even after weighting, fault diagnosis model 15B and the new fault diagnosis model are discarded to prevent erroneous fault diagnosis, and the target part is excluded from the target of the fault diagnosis system.

Next, the model update process performed by the fault diagnosis device 10 according to the second embodiment will be described in detail with reference to FIG. 11.

Figure 11 is a flowchart showing an example of the flow of model update processing by the fault diagnosis program 15A according to the second embodiment.

First, the CPU 11 starts the fault diagnosis program 15A stored in the memory unit 15, and executes the steps shown below. In this embodiment, when the performance of the fault diagnosis model 15B deteriorates over time, the fault diagnosis model 15B is re-learned.

In step S151 in FIG. 11, the CPU 11 acquires the diagnosis result (e.g., faulty or healthy) of the fault diagnosis model 15B (current fault diagnosis model) for an arbitrary part, and transmits the acquired diagnosis result to the maintenance terminal 70. Then, if the diagnosis result is a fault, the worker 60 who owns the maintenance terminal 70 performs fault diagnosis work on the target part at the site and checks whether the target part is faulty or healthy. Then, the worker 60 inputs the confirmation result of whether the target part is faulty or healthy via the maintenance terminal 70.

In step S152, the CPU 11 accepts input of the confirmation results of the failure or soundness of the target part from the worker 60 via the maintenance terminal 70.

In step S153, the CPU 11 stores in the memory unit 15 a set of the operation history data used to diagnose the fault of the target part and the verification results of the target part.

In step S154, the CPU 11 updates the performance of the fault diagnosis model 15B using the operation history data and confirmation results stored in the memory unit 15 in step S153.

In step S155, the CPU 11 determines whether the performance of the fault diagnosis model 15B, whose performance was updated in step S154, has deteriorated over time. If it is determined that the performance of the fault diagnosis model 15B has deteriorated over time (if the determination is positive), the process proceeds to step S156, and if it is determined that the performance of the fault diagnosis model 15B has not deteriorated over time (if the determination is negative), the process returns to step S151 and is repeated.

In step S156, the CPU 11 re-learns the fault diagnosis model 15B to generate a new fault diagnosis model. The learning data used for re-learning is a set of the most recent operation history data used in fault diagnosis by the fault diagnosis model 15B and its correct answer data.

In step S157, the CPU 11 judges whether the generalization performance of the new fault diagnosis model generated in step S156 is equal to or higher than a certain level for the most recent data. If it is judged that the generalization performance of the new fault diagnosis model is equal to or higher than a certain level for the most recent data (if the judgment is positive), the process proceeds to step S158. If it is judged that the generalization performance of the new fault diagnosis model is lower than a certain level for the most recent data (if the judgment is negative), the process proceeds to step S159.

In step S158, the CPU 11 updates the fault diagnosis model 15B to the new fault diagnosis model generated in step S156, that is, adopts and deploys the new model, and ends the series of processes performed by this fault diagnosis program 15A.

On the other hand, in step S159, the CPU 11 weights the most recent data, which is the test data during relearning.

In step S160, the CPU 11 re-learns the fault diagnosis model 15B using the most recent data weighted in step S159, and generates a second new fault diagnosis model.

In step S161, the CPU 11 judges whether the generalization performance of the second new fault diagnosis model generated in step S160 is equal to or higher than a certain level for the most recent weighted data. If it is judged that the generalization performance of the second new fault diagnosis model is equal to or higher than a certain level for the most recent weighted data (if the judgment is positive), the process proceeds to step S158, and if it is judged that the generalization performance of the second new fault diagnosis model is lower than the certain level for the most recent weighted data (if the judgment is negative), the process proceeds to step S162.

In step S162, the CPU 11 discards the current fault diagnosis model, fault diagnosis model 15B.

In step S163, the CPU 11 discards the new fault diagnosis model generated in step S156 and the second new fault diagnosis model generated in step S160.

In step S164, since there is no fault diagnosis model that meets a certain standard for the target part, the CPU 11 sets the target part as outside the scope of the fault diagnosis system, and ends the series of processes by this fault diagnosis program 15A.

In the present embodiment, the fault diagnosis device 10 is implemented as an external server device, but this is not limiting. The fault diagnosis device 10 may also be implemented as the control device 41 of the CGS 40.

In this way, according to this embodiment, if the performance of the fault diagnosis model used to diagnose faults in the fuel cell cogeneration system deteriorates over time, the fault diagnosis model can be re-learned and updated. This makes it possible to maintain the performance of the fault diagnosis model at a certain level or higher.

[Third embodiment]
In the third embodiment, a form will be described in which the fault diagnosis model is re-learned when the number of data items on which fault diagnosis has been performed using the fault diagnosis model exceeds a certain value.

The fault diagnosis device according to the third embodiment has the same components as the fault diagnosis device 10 according to the first embodiment, and will therefore be described with reference to FIG. 5 above.

In this embodiment, the predetermined condition is that the number of data items diagnosed by fault diagnosis model 15B exceeds a certain value.

When the number of data items diagnosed by the fault diagnosis model 15B exceeds a certain value, the learning unit 11C generates a new fault diagnosis model using the past operation history data group used for the fault diagnosis as learning data. Then, when the generalization performance of the new fault diagnosis model is higher than the generalization performance of the fault diagnosis model 15B, the learning unit 11C updates the fault diagnosis model 15B to the new fault diagnosis model.

In addition, the learning unit 11C discards the new fault diagnosis model if the generalization performance of the new fault diagnosis model is equal to or lower than the generalization performance of the fault diagnosis model 15B.

In this embodiment, the basic process is the same as the process described in the first embodiment (see FIG. 8). However, when implemented simultaneously with at least one of the processes described in the first and second embodiments, if the generalization performance of the new fault diagnosis model is equal to or lower than that of fault diagnosis model 15B (current fault diagnosis model), the new fault diagnosis model is discarded, and fault diagnosis model 15B continues to be used as is. Therefore, the target part will not be excluded from the target of the fault diagnosis system. On the other hand, if not implemented simultaneously with the first and second embodiments, there is a possibility that the generalization performance of both fault diagnosis model 15B and the new fault diagnosis model will fall below a certain level. For this reason, a process of comparison with the standard generalization performance and a process of discarding both fault diagnosis models when the performance is not reached are added.

Next, the model update process performed by the fault diagnosis device 10 according to the third embodiment will be described in detail with reference to FIG. 12.

Figure 12 is a flowchart showing an example of the flow of model update processing by the fault diagnosis program 15A according to the third embodiment.

First, the CPU 11 starts the fault diagnosis program 15A stored in the memory unit 15, and executes the steps shown below. In this embodiment, if the performance of the fault diagnosis model 15B does not reach a certain level, the fault diagnosis model 15B is re-learned.

In step S171 of FIG. 12, the CPU 11 acquires the diagnosis result (e.g., faulty or healthy) of the fault diagnosis model 15B (current fault diagnosis model) for an arbitrary part, and transmits the acquired diagnosis result to the maintenance terminal 70. Then, if the diagnosis result is a fault, the worker 60 who owns the maintenance terminal 70 performs fault diagnosis work on the target part at the site and checks whether the target part is faulty or healthy. Then, the worker 60 inputs the confirmation result of whether the target part is faulty or healthy via the maintenance terminal 70.

In step S172, the CPU 11 accepts input of the confirmation results of the failure or soundness of the target part from the worker 60 via the maintenance terminal 70.

In step S173, the CPU 11 stores in the memory unit 15 a set of the operation history data used to diagnose the fault of the target part and the verification results of the target part.

In step S174, the CPU 11 updates the performance of the fault diagnosis model 15B using the operation history data and confirmation results stored in the memory unit 15 in step S173.

In step S175, the CPU 11 increments the counter for the number of data items.

In step S176, the CPU 11 determines whether the counter value incremented in step S175 is greater than n. If it is determined that the counter value is greater than n (if the determination is positive), the process proceeds to step S177, and if it is determined that the counter value is equal to or less than n (if the determination is negative), the process returns to step S171 and repeats the process.

In step S177, the CPU 11 re-learns the fault diagnosis model 15B to generate a new fault diagnosis model. The learning data used for re-learning is a set of past operation history data and its correct answer data used in fault diagnosis by the fault diagnosis model 15B.

In step S178, the CPU 11 judges whether the generalization performance of the new fault diagnosis model generated in step S177 is higher than the generalization performance of the fault diagnosis model 15B. If it is judged that the generalization performance of the new fault diagnosis model is higher than the generalization performance of the fault diagnosis model 15B (if the judgment is positive), the process proceeds to step S179, and if it is judged that the generalization performance of the new fault diagnosis model is equal to or lower than the generalization performance of the fault diagnosis model 15B (if the judgment is negative), the process proceeds to step S180.

In step S179, the CPU 11 updates the fault diagnosis model 15B to the new fault diagnosis model generated in step S177, that is, adopts and deploys the new model, and then proceeds to step S181.

On the other hand, in step S180, the CPU 11 discards the new fault diagnosis model generated in step S177, and proceeds to step S181. If both the current fault diagnosis model and the new fault diagnosis model are below a certain level, both models may be discarded and excluded from the fault diagnosis system.

In step S181, the CPU 11 initializes the counter and ends the series of processes performed by this fault diagnosis program 15A.

In the present embodiment, the fault diagnosis device 10 is implemented as an external server device, but this is not limiting. The fault diagnosis device 10 may also be implemented as the control device 41 of the CGS 40.

In this way, according to this embodiment, when the number of data items diagnosed by the fault diagnosis model used to diagnose faults in a fuel cell cogeneration system exceeds a certain value, the fault diagnosis model can be re-learned and updated. This makes it possible to maintain the performance of the fault diagnosis model at a certain level or higher.

[Fourth embodiment]
In the fourth embodiment, a form will be described in which the fault diagnosis model is re-learned when a period during which fault diagnosis has been performed using the fault diagnosis model exceeds a certain period.

The fault diagnosis device according to the fourth embodiment has the same components as the fault diagnosis device 10 according to the first embodiment, and will therefore be described with reference to FIG. 5 above.

In this embodiment, the predetermined condition is that the period during which fault diagnosis is performed using fault diagnosis model 15B exceeds a certain period.

When the period during which fault diagnosis was performed using fault diagnosis model 15B exceeds a certain period, learning unit 11C generates a new fault diagnosis model using a group of past operation history data used in the fault diagnosis as learning data. Then, when the generalization performance of the new fault diagnosis model is higher than the generalization performance of fault diagnosis model 15B, learning unit 11C updates fault diagnosis model 15B to the new fault diagnosis model.

In addition, the learning unit 11C discards the new fault diagnosis model if the generalization performance of the new fault diagnosis model is equal to or lower than the generalization performance of the fault diagnosis model 15B.

In this embodiment, the basic process is the same as the process described in the first embodiment (see FIG. 8). However, when implemented simultaneously with at least one of the processes described in the first and second embodiments, if the generalization performance of the new fault diagnosis model is equal to or lower than that of fault diagnosis model 15B (current fault diagnosis model), the new fault diagnosis model is discarded, and fault diagnosis model 15B continues to be used as is. Therefore, the target part will not be excluded from the target of the fault diagnosis system. On the other hand, if not implemented simultaneously with the first and second embodiments, there is a possibility that the generalization performance of both fault diagnosis model 15B and the new fault diagnosis model will fall below a certain level. For this reason, a process of comparison with the standard generalization performance and a process of discarding both fault diagnosis models when the performance is not reached are added.

Next, the model update process performed by the fault diagnosis device 10 according to the fourth embodiment will be described in detail with reference to FIG. 13.

Figure 13 is a flowchart showing an example of the flow of model update processing by the fault diagnosis program 15A according to the fourth embodiment.

First, the CPU 11 starts the fault diagnosis program 15A stored in the memory unit 15, and executes the steps shown below. In this embodiment, if the performance of the fault diagnosis model 15B does not reach a certain level, the fault diagnosis model 15B is re-learned.

In step S191 of FIG. 13, the CPU 11 acquires the diagnosis result (e.g., faulty or healthy) of the fault diagnosis model 15B (current fault diagnosis model) for an arbitrary part, and transmits the acquired diagnosis result to the maintenance terminal 70. Then, if the diagnosis result is a fault, the worker 60 who owns the maintenance terminal 70 performs fault diagnosis work on the target part at the site and checks whether the target part is faulty or healthy. Then, the worker 60 inputs the confirmation result of whether the target part is faulty or healthy via the maintenance terminal 70.

In step S192, the CPU 11 accepts input of the confirmation results of the failure or soundness of the target part from the worker 60 via the maintenance terminal 70.

In step S193, the CPU 11 stores in the memory unit 15 a set of the operation history data used to diagnose the fault of the target part and the verification results of the target part.

In step S194, the CPU 11 updates the performance of the fault diagnosis model 15B using the operation history data and confirmation results stored in the memory unit 15 in step S193.

In step S195, the CPU 11 determines whether the application period of the fault diagnosis model 15B whose performance was updated in step S194 is longer than m. If it is determined that the application period is longer than m (if a positive determination), the process proceeds to step S196, and if it is determined that the application period is equal to or shorter than m (if a negative determination), the process returns to step S191 and is repeated.

In step S196, the CPU 11 re-learns the fault diagnosis model 15B to generate a new fault diagnosis model. The learning data used for re-learning is a set of past operation history data and its correct answer data used in fault diagnosis by the fault diagnosis model 15B.

In step S197, the CPU 11 judges whether the generalization performance of the new fault diagnosis model generated in step S196 is higher than the generalization performance of the fault diagnosis model 15B. If it is judged that the generalization performance of the new fault diagnosis model is higher than the generalization performance of the fault diagnosis model 15B (if the judgment is positive), the process proceeds to step S198. If it is judged that the generalization performance of the new fault diagnosis model is equal to or lower than the generalization performance of the fault diagnosis model 15B (if the judgment is negative), the process proceeds to step S199.

In step S198, the CPU 11 updates the fault diagnosis model 15B to the new fault diagnosis model generated in step S196, that is, adopts and deploys the new model, and ends the series of processes performed by this fault diagnosis program 15A.

On the other hand, in step S199, the CPU 11 discards the new fault diagnosis model generated in step S196, and ends the series of processes by the fault diagnosis program 15A. Note that if both the current fault diagnosis model and the new fault diagnosis model are below a certain level, both models may be discarded and excluded from the fault diagnosis system.

In the present embodiment, the fault diagnosis device 10 is implemented as an external server device, but this is not limiting. The fault diagnosis device 10 may also be implemented as the control device 41 of the CGS 40.

In this way, according to this embodiment, when the period during which a fault diagnosis is performed using a fault diagnosis model used to diagnose a fault in a fuel cell cogeneration system exceeds a certain period, the fault diagnosis model can be re-learned and updated. This makes it possible to maintain the performance of the fault diagnosis model at a certain level or higher.

Although the above embodiments have been described by way of example using a fault diagnosis device and a fault diagnosis system, each embodiment may be in the form of a program for causing a computer to execute the functions of each unit of the fault diagnosis device. Each embodiment may be in the form of a computer-readable storage medium that stores the program.

In addition, the configurations of the fault diagnosis device and fault diagnosis system described in each of the above embodiments are merely examples, and may be modified according to circumstances without departing from the spirit of the invention.

The processing flow of the program described in each of the above embodiments is also an example, and unnecessary steps may be deleted, new steps may be added, or the processing order may be rearranged, without departing from the spirit of the invention.

In addition, in each of the above embodiments, a case has been described in which the processing according to each embodiment is realized by a software configuration using a computer by executing a program, but this is not limited to this. Each embodiment may be realized, for example, by a hardware configuration or a combination of a hardware configuration and a software configuration.

10 Fault diagnosis device 11, 42 CPU
11A Acquisition unit 11B Estimation unit 11C Learning unit 11D First output unit 11E Second output unit 12, 43 ROM
13, 44 RAM
14, 45 I/O
15, 46 Storage unit 15A Fault diagnosis program 15B Fault diagnosis model 16 Display unit 17 Operation unit 18, 47 Communication unit 30 User's home 40 CGS
41 Control device 46A Control program 48 Device I/F
49 CGS main body 50 Fuel cell unit 51 Fuel cell module 51A Fuel cell stack 51B Reformer 52 Gas path 53 Reformed water path 54 Air path 60 Worker 70 Maintenance terminal 100 Fault diagnosis system

Claims (12)

an acquisition unit that acquires, when the fuel cell cogeneration system detects an operational abnormality, from the fuel cell cogeneration system, operation history data related to the operation history of the fuel cell cogeneration system that corresponds to the abnormality;
an estimation unit which inputs the operation history data acquired by the acquisition unit or data obtained by processing the operation history data into a fault diagnosis model which is generated by performing machine learning or multivariate analysis on a group of previously acquired operation history data in association with functional units of the fuel cell cogeneration system and judges the presence or absence of a fault for each functional unit of the fuel cell cogeneration system, and which estimates the presence or absence of a fault for each functional unit of the fuel cell cogeneration system using the judgment result output from the fault diagnosis model;
a learning unit that generates a new fault diagnosis model by re-learning the fault diagnosis model when the fault diagnosis model satisfies a predetermined condition;
Equipped with
The predetermined condition includes at least one of the following conditions: a condition that the performance of the fault diagnosis model does not reach a certain level; a condition that the performance of the fault diagnosis model deteriorates over time; a condition that the number of data items for which fault diagnosis has been performed using the fault diagnosis model exceeds a certain value; and a condition that the period for which fault diagnosis has been performed using the fault diagnosis model exceeds a certain period.
Fault diagnosis device. the predetermined condition is a condition that the performance of the fault diagnosis model does not reach a certain level;
2. The fault diagnosis device according to claim 1, wherein the learning unit generates a new fault diagnosis model using a group of past operation history data used for fault diagnosis as learning data when performance of the fault diagnosis model does not reach a certain level, and updates the fault diagnosis model to the new fault diagnosis model when generalization performance of the new fault diagnosis model is equal to or higher than a certain level. The fault diagnosis device according to claim 2 , wherein the learning unit discards the fault diagnosis model and the new fault diagnosis model when a generalization performance of the new fault diagnosis model is below a certain level. the predetermined condition is a condition that the performance of the fault diagnosis model deteriorates over time,
2. The fault diagnosis device according to claim 1, wherein the learning unit generates a new fault diagnosis model using a group of most recent operation history data used for the fault diagnosis as learning data when performance of the fault diagnosis model deteriorates over time, and updates the fault diagnosis model to the new fault diagnosis model when generalization performance of the new fault diagnosis model is equal to or higher than a certain level. 5. The fault diagnosis device according to claim 4, wherein, when a generalization performance of the new fault diagnosis model is below a certain level, the learning unit weights the most recent operation history data group, generates a second new fault diagnosis model using the weighted most recent operation history data group as learning data, and, when a generalization performance of the second new fault diagnosis model is equal to or higher than a certain level, updates the fault diagnosis model to the second new fault diagnosis model. The fault diagnosis device according to claim 5 , wherein the learning unit discards the fault diagnosis model, the new fault diagnosis model, and the second new fault diagnosis model when a generalization performance of the second new fault diagnosis model is below a certain level. the predetermined condition being that the number of data items diagnosed by the fault diagnosis model exceeds a certain value;
2. The fault diagnosis device according to claim 1, wherein the learning unit generates a new fault diagnosis model using a group of past operation history data used for the fault diagnosis as learning data when a number of data items diagnosed by the fault diagnosis model exceeds a certain value, and updates the fault diagnosis model to the new fault diagnosis model when a generalization performance of the new fault diagnosis model is higher than a generalization performance of the fault diagnosis model. the predetermined condition is that a period during which a fault diagnosis has been performed using the fault diagnosis model exceeds a certain period;
2. The fault diagnosis device according to claim 1, wherein the learning unit generates a new fault diagnosis model using a group of past operation history data used for the fault diagnosis as learning data when a period during which fault diagnosis has been performed using the fault diagnosis model exceeds a certain period, and updates the fault diagnosis model to the new fault diagnosis model when a generalization performance of the new fault diagnosis model is higher than a generalization performance of the fault diagnosis model. The fault diagnosis device according to claim 7 or 8, wherein the learning unit discards the new fault diagnosis model when a generalization performance of the new fault diagnosis model is equal to or lower than a generalization performance of the fault diagnosis model. 10. The fault diagnosis device according to claim 2, wherein at least one of a precision rate at the time of fault determination and a recall rate of fault detection is used as an index representing the performance or generalization performance of the fault diagnosis model. A fuel cell cogeneration system;
a fault diagnosis device connected to the fuel cell cogeneration system;
Equipped with
The fuel cell cogeneration system comprises:
When an abnormality in the operation of the system is detected, operation history data on the operation history of the system corresponding to the abnormality is transmitted to the fault diagnosis device;
The fault diagnosis device includes:
an acquisition unit that acquires the operation history data transmitted from the fuel cell cogeneration system;
an estimation unit which inputs the operation history data acquired by the acquisition unit or data obtained by processing the operation history data into a fault diagnosis model which is generated by performing machine learning or multivariate analysis on a group of previously acquired operation history data in association with functional units of the fuel cell cogeneration system and judges the presence or absence of a fault for each functional unit of the fuel cell cogeneration system, and which estimates the presence or absence of a fault for each functional unit of the fuel cell cogeneration system using the judgment result output from the fault diagnosis model;
a learning unit that generates a new fault diagnosis model by re-learning the fault diagnosis model when the fault diagnosis model satisfies a predetermined condition;
Equipped with
The predetermined condition includes at least one of the following conditions: a condition that the performance of the fault diagnosis model does not reach a certain level; a condition that the performance of the fault diagnosis model deteriorates over time; a condition that the number of data items for which fault diagnosis has been performed using the fault diagnosis model exceeds a certain value; and a condition that the period for which fault diagnosis has been performed using the fault diagnosis model exceeds a certain period.
Fault diagnosis system. A fault diagnosis program for causing a computer to function as each unit included in the fault diagnosis device according to any one of claims 1 to 10.