Damage management system

Abstract

[Problem] To provide a damage management system which makes it easy to manage the status of occurrence of damage. [Solution] One aspect of the present invention provides a damage management system. The damage management system comprises a processor. The processor is configured to perform a forecasting step, a first receiving step, and a recording step. In the forecasting step, a possibility of a damage which might occur in a plant is transmitted to a first user terminal as a forecast value. In the first receiving step, input of an occurrence value that indicates whether or not the damage for which the forecast value has been transmitted occurs is received from the first user terminal. In the recording step, the occurrence value is recorded together with the type of the plant associated with the forecast value, a habitat associated with a user ID of the first user terminal, and the input date and time of the occurrence value.

Description

Fault Management System

[0001] The present invention relates to a fault management system.

[0002] As disclosed in the following documents, a device that predicts damage (diseases, pests, and physiological damage) that occurs in plants (crops) using a learning model is known.

[0003] Japanese Patent Application Laid-Open No. 2021-93957

[0004] The above-mentioned device has a function for the user to input whether or not a failure has occurred in response to a predicted failure, but the user must register the type and habitat of the plant where the failure occurred.

[0005] In view of the above circumstances, the present invention provides a fault management system that can easily manage the occurrence of faults.

[0006] According to one aspect of the present invention, there is provided a fault management system. The fault management system includes a processor. The processor is configured to execute a forecasting step, a first receiving step, and a recording step. In the forecasting step, a possibility of a fault occurring in a plant is transmitted to a first user terminal as a forecast value. In the first receiving step, an input of an occurrence value indicating whether or not the fault for which the forecast value was transmitted has occurred is received from the first user terminal. In the recording step, the occurrence value is recorded together with the type of plant linked to the forecast value, the habitat linked to the user ID of the first user terminal, and the date and time when the occurrence value was input.

[0007] According to this aspect, by inputting a response to the forecast value transmitted to the first user terminal, the occurrence or non-occurrence of a fault can be easily registered along with the type of plant, its habitat, and the date and time of the fault, thereby facilitating the management of the fault occurrence status.

[0008] 1 is a configuration diagram showing the fault management system 1. FIG. 1 is a block diagram showing the hardware configuration of an information processing device 2. FIG. 2 is a block diagram showing the hardware configuration of a first user terminal 3 and a second user terminal 4. FIG. 3 is a block diagram showing functions realized by the information processing device 2 (processor 23). FIG. 4 is a diagram showing an example of a disease forecast screen BD1 displayed on the first user terminal 3. FIG. 5 is a diagram showing an example of a pest forecast screen BD2 displayed on the first user terminal 3. FIG. 6 is a diagram showing an example of changes in the occurrence input button OB and the countermeasure input button CB. FIG. 7 is a diagram showing an example of a pesticide input screen PR displayed on the first user terminal 3. FIG. 8 is an example of a history screen HD displayed on the first user terminal 3. FIG. 9 is an example of a map screen MD displayed on the first user terminal 3. FIG. 10 is an activity diagram showing the flow of information processing (fault occurrence recording processing) executed by the fault management system 1.

[0009] DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS The present invention will be described below with reference to the accompanying drawings. Various features shown in the following embodiments can be combined with each other.

[0010] Incidentally, the program for realizing the software appearing in this embodiment may be provided as a non-transitory computer-readable recording medium, or may be provided so as to be downloadable from an external server, or may be provided so that the program is started on an external computer and its functions are realized on a client terminal (so-called cloud computing).

[0011] In this embodiment, the term "unit" may include, for example, a combination of hardware resources implemented by a circuit in the broad sense and software information processing that can be specifically realized by these hardware resources. In addition, various types of information are handled in this embodiment, and this information may be represented by, for example, physical values ​​of signal values ​​representing voltages and currents, high and low signal values ​​as a binary bit set consisting of 0 or 1, or quantum superposition (so-called quantum bits), and communication and calculations may be performed on a circuit in the broad sense.

[0012] Furthermore, a circuit in the broad sense is a circuit realized by at least an appropriate combination of a circuit, circuitry, a processor, a memory, etc. That is, it includes an application specific integrated circuit (ASIC), a programmable logic device (e.g., a simple programmable logic device (SPLD), a complex programmable logic device (CPLD), and a field programmable gate array (FPGA)), etc.

[0013] 1. Hardware Configuration This section explains the hardware configuration.

[0014] 1 is a configuration diagram showing the fault management system 1. The fault management system 1 provides a service to multiple users that forecasts faults that may occur in plants (mainly agricultural crops) and manages the status of fault occurrence.

[0015] The fault management system 1 includes an information processing device 2, a first user terminal 3, and a second user terminal 4. The information processing device 2, the first user terminal 3, and the second user terminal 4 are configured to be able to communicate with each other via a telecommunications line. In one embodiment, the fault management system 1 is made up of one or more devices or components. For example, if the fault management system 1 is made up of only the information processing device 2, the fault management system 1 can be the information processing device 2. These components will be described below.

[0016] 2 is a block diagram showing the hardware configuration of the information processing device 2. The information processing device 2 includes a communication bus 20, a communication unit 21, a storage unit 22, and a processor 23. The communication unit 21, the storage unit 22, and the processor 23 are electrically connected via the communication bus 20 inside the information processing device 2.

[0017] <Communication Unit 21> The communication unit 21 is preferably a wired communication means such as USB, IEEE 1394, Thunderbolt (registered trademark), or wired LAN network communication, but may also include wireless LAN network communication, mobile communication such as 3G / LTE / 5G, or BLUETOOTH (registered trademark) communication as needed. In other words, it is more preferable to implement the communication unit 21 as a collection of multiple communication means. In other words, the information processing device 2 may communicate various information from the outside via the communication unit 21 and the network.

[0018] <Storage Unit 22> The storage unit 22 stores various pieces of information defined above. This may be implemented, for example, as a storage device such as a solid state drive (SSD) that stores various programs and the like related to the information processing device 2 executed by the processor 23, or as a memory such as a random access memory (RAM) that stores temporarily required information (arguments, arrays, etc.) related to program calculations. The storage unit 22 stores various programs, variables, etc. related to the information processing device 2 executed by the processor 23.

[0019] <Processor 23> The processor 23 processes and controls the overall operations related to the information processing device 2. The processor 23 is, for example, a central processing unit (CPU). The processor 23 realizes various functions related to the information processing device 2 by reading out predetermined programs stored in the storage unit 22. In other words, information processing by software stored in the storage unit 22 is specifically realized by the processor 23, which is an example of hardware, and can be executed as each functional unit included in the processor 23. These will be described in more detail in the next section. Note that the processor 23 is not limited to being single, and multiple processors 23 may be provided for each function. A combination of these may also be used.

[0020] <First User Terminal 3> Figure 3 is a block diagram showing the hardware configuration of the first user terminal 3 and the second user terminal 4. As shown in Figure 3A, the first user terminal 3 includes a communication bus 30, a communication unit 31, a storage unit 32, a processor 33, a display unit 34, and an input unit 35. The communication unit 31, the storage unit 32, the processor 33, the display unit 34, and the input unit 35 are electrically connected via the communication bus 30 inside the first user terminal 3. The description of the communication unit 31, the storage unit 32, and the processor 33 is omitted because it is the same as the description of each unit in the information processing device 2.

[0021] <Display Unit 34> The display unit 34 displays a screen of a graphical user interface (GUI) that can be operated by the user. The display unit 34 may be included in the housing of the first user terminal 3 or may be externally attached. Specifically, the display unit 34 may be implemented as a display device such as a CRT display, a liquid crystal display, an organic EL display, or a plasma display. It is preferable that these display devices are implemented by selectively using them depending on the type of the first user terminal 3.

[0022] <Input Unit 35> The input unit 35 accepts operation inputs made by the user. The operation inputs are transferred as command signals to the processor 33 via the communication bus 30. The processor 33 can execute predetermined control or calculations based on the transferred command signals as necessary. The input unit 35 may be included in the housing of the first user terminal 3 or may be externally attached. For example, the input unit 35 may be implemented as a touch panel integrated with the display unit 34. When the input unit 35 is implemented as a touch panel, the user can input tap operations, swipe operations, etc. to the input unit 35. Instead of a touch panel, a switch button, a mouse, a QWERTY keyboard, etc. can be used as the input unit 35.

[0023] 3B , the second user terminal 4 includes a communication bus 40, a communication unit 41, a storage unit 42, a processor 43, a display unit 44, and an input unit 45. The communication unit 41, the storage unit 42, the processor 43, the display unit 44, and the input unit 45 are electrically connected via the communication bus 40 inside the second user terminal 4. The description of the communication unit 41, the storage unit 42, the processor 43, the display unit 44, and the input unit 45 is omitted because they are the same as the description of each unit in the first user terminal 3.

[0024] The information processing device 2 may be an on-premise type or a cloud type. As the information processing device 2 in the cloud type, for example, the above-described functions and processes may be provided in the form of SaaS (Software as a Service) or cloud computing.

[0025] 2. Functional Configuration This section describes the functional configuration of this embodiment. Information processing by software stored in the storage unit 22 is specifically realized by the processor 23, which is an example of hardware, and can be executed as each functional unit included in the processor 23.

[0026] 4 is a block diagram showing functions realized by the information processing device 2 (processor 23). Specifically, the information processing device 2 (processor 23) includes a registration unit 231, a forecast unit 232, a first reception unit 233, a recording unit 234, a history output unit 235, a reminding unit 236, a second reception unit 237, and a sharing unit 238.

[0027] <Registration Unit 231> The registration unit 231 registers first users (mainly farmers) who use the first user terminal 3. Specifically, the registration unit 231 registers user data including the user ID, the type of plant (crop) being cultivated, and the managed habitat (address of the field) in addition to the first user's personal information (name, address, contact information, etc.). For a first user who has multiple habitats, the registration unit 231 registers the addresses of the multiple habitats.

[0028] The registration unit 231 also registers second users (mainly farm instructors) who use the second user terminal 4. Specifically, the registration unit 231 registers personal information (organization, person in charge, contact information, etc.) and user IDs of the second users.

[0029] <Forecasting Unit> The forecasting unit 232 transmits the possibility of damage occurring to plants as a forecast value to the first user terminal 3. Damage includes disease, pests, and physiological damage. Physiological damage includes deficiencies of elements such as magnesium and calcium, and water shortages. The forecasting unit 232 displays a damage occurrence forecast including the forecast value on the first user terminal 3.

[0030] The forecasting unit 232 predicts the probability of occurrence of a problem for a "plant type" (i.e., a forecast value) for each "type of problem." "Plant types" include, for example, varieties such as strawberries, radishes, onions, broccoli, and cabbage. Furthermore, "plant types" may be further subdivided by subcategories such as varieties of crops such as onions, such as "Sonic" and "Neo Earth," or harvest days, such as "early" and "mid-season." "Types of problem" include, for example, disease names such as black sooty mold and black rot, pest names such as armyworms and aphids, or physiological disease phenomena such as magnesium deficiency and water deficiency.

[0031] The forecasting unit 232 predicts the possibility of a failure using a learning model (artificial intelligence) that has undergone machine learning in advance. Specifically, the forecasting unit 232 inputs the type of plant to be predicted, the region, and the date into the learning model, and causes the learning model to output at least one failure that may occur and the probability (forecast value) of occurrence of each of the at least one failure.

[0032] Specifically, the forecast unit 232 inputs the type and habitat of the plant included in the user data of the first user using the first user terminal 3 that transmits the forecast value, and the date on which the forecast value is to be issued, into the learning model. The forecast unit 232 also transmits the forecast value corresponding to the type of plant and the type of damage output from the learning model to the first user terminal 3. In other words, the forecast unit 232 transmits the possibility of each of multiple types of damage that may occur to plants as a forecast value to the first user terminal 3.

[0033] The learning model used by the forecasting unit 232 is constructed by machine learning using training data that includes records associating the type of plant that has previously experienced a problem, the type of problem that occurred, the area where the plant grew, and the date the problem occurred. Specific machine learning algorithms include nearest neighbor methods, naive Bayes methods, decision trees, support vector machines, deep learning using neural networks, and regression models. This learning model can perform additional learning using data received from the first user terminal 3.

[0034] 5 is a diagram showing an example of a disease forecast screen BD1 displayed on the first user terminal 3. The forecast screen BD1 is created based on forecast values ​​transmitted from the forecast unit 232. The forecast screen BD1 includes a selection area SP for selecting the type of plant, and a disease display area DP1 for displaying diseases that may occur in the selected plant.

[0035] A plurality of plant icons are displayed in the selection area SP. The type of plant for which forecast values ​​are to be displayed is selected by pressing an icon using an input device (e.g., a mouse, a trackpad, a touch panel, etc.) on the first user terminal 3. A selection mark SM is attached to the selected plant icon.

[0036] Depending on the type of plant selected in the selection area SP, multiple disease display areas DP1 are displayed on the forecast screen BD1. Each disease display area DP1 includes a symptom photo CP, a disease name DT, a forecast value FV, a variation value CV, and an occurrence input button OB.

[0037] The forecast value FV is a probability indicating the possibility of occurrence of the disease displayed as the disease name DT, predicted by the forecasting unit 232. In the disease display area DP1, a graph indicating the magnitude of the forecast value FV and a forecast level linked to the forecast value FV are displayed above the forecast value FV. The forecast level is displayed in stages, such as "watch," "caution," and "alert," depending on the magnitude of the forecast value FV.

[0038] The variation value CV indicates the increase or decrease in the current (i.e., displayed in the disease display area DP1) forecast value FV compared to the past forecast value FV on a specified date (e.g., the day before or the day the forecast value FV was last displayed).

[0039] The occurrence input button OB is a button that the first user presses when a disorder (disease) displayed in the disease display area DP1 occurs in the habitat managed by the first user (i.e., the habitat for which the forecast value was issued).

[0040] 6 is a diagram showing an example of a pest forecast screen BD2 displayed on the first user terminal 3. The forecast screen BD2 is created based on forecast values ​​transmitted from the forecast unit 232. The forecast screen BD2 includes a selection area SP for selecting a plant type, and a pest display area DP2 for displaying pests that may occur in the selected plant.

[0041] The selection area SP is the same as the forecast screen BD1 in Figure 5. Depending on the type of plant selected in the selection area SP, multiple pest display areas DP2 are displayed on the forecast screen BD2. One pest display area DP2 includes a pest name PT, a symptom photo CP, a forecast value FV, a variation value CV, an occurrence input button OB, and a countermeasure input button CB. The forecast value FV, variation value CV, and occurrence input button OB are the same as those on the forecast screen BD1 in Figure 5. The countermeasure input button CB is a button that the first user presses when taking countermeasures against a problem.

[0042] The disease display area DP1 and the pest display area DP2 may be displayed on one forecast screen. The forecast screen may also display an area for displaying forecast values ​​for physiological disorders.

[0043] In addition to the forecast value, the forecast unit 232 may transmit information on the occurrence of failures in nearby habitats to the first user terminal 3. The failure occurrence information includes the type of failure occurring in the nearby habitat, the number of failures, the pesticide spraying status (type of pesticide, spraying date, etc.), etc.

[0044] Furthermore, the forecasting unit 232 may present countermeasures for the problem in addition to the forecast value, such as pesticides that are effective against the problem, fertilizers containing the missing components, and the like.

[0045] <First Receiving Unit 233> The first receiving unit 233 receives an input of an occurrence value indicating whether or not a failure for which a forecast value has been transmitted has occurred from the first user terminal 3. Specifically, in response to pressing the occurrence input button OB in the disease display area DP1 or the pest display area DP2, the first receiving unit 233 receives a value (code) indicating that "the corresponding failure has occurred" from the first user terminal 3.

[0046] When the occurrence input button OB is pressed, the first reception unit 233 may subsequently display a confirmation pop-up screen to receive the confirmation input (pressing the button), or may perform registration (receive the code) without displaying the pop-up screen. If the first reception unit 233 does not display the pop-up screen, it may display a message such as "Cabbage disease A has been registered at the current location" on the first user terminal 3 for a certain period of time (e.g., 3 seconds).

[0047] That is, the first reception unit 233 accepts input of the occurrence value by a single action (pressing a button once) or a double action (pressing a button twice) from the state where the forecast value is displayed on the first user terminal 3 (the state where the disease display area DP1 or the pest display area DP2 is displayed).

[0048] 7 is a diagram showing an example of changes in the occurrence input button OB and the countermeasure input button CB. When the occurrence input button OB is pressed, as shown in FIG. 7, the input reception by the first reception unit 233 is emphasized by changing the color, changing the size, adding an icon, etc.

[0049] The occurrence value may be selected from a range of options with degrees (e.g., "large occurrence amount," "small occurrence amount," "no occurrence," etc.). Furthermore, the first accepting unit 233 may accept any numerical value (e.g., a numerical value proportional to the degree of occurrence) input by the first user as the occurrence value.

[0050] The first reception unit 233 further receives input of the type and date of spraying of the pesticide sprayed in response to the failure for which the forecast value was transmitted from the first user terminal 3. Specifically, the first reception unit 233 receives the type and date of spraying of the pesticide input by the first user from the first user terminal 3.

[0051] Fig. 8 is a diagram showing an example of a pesticide input screen PR displayed on the first user terminal 3. When the countermeasure input button CB shown in Fig. 6 is pressed, the pesticide input screen PR shown in Fig. 8A is displayed on the first user terminal 3. The pesticide input screen PR includes a habitat input field FI, a pesticide input field PI, an application date input field DI, a send button B1, and a cancel button B2.

[0052] The habitat input field FI accepts input of the habitat (field) where the pesticide was sprayed. Initially, the habitat input field FI contains the address of the managed habitat (i.e., the habitat where the forecast value was received) registered in the user data of the first user. If the pesticide was sprayed in a habitat different from the registered habitat, the first user manually enters the address of the habitat where the pesticide was sprayed or by linking with an external map application. The first accepting unit 233 may display (i.e., pre-enter) in the habitat input field FI the managed habitat registered in the user data that is closest to the location information transmitted from the first user terminal 3.

[0053] The pesticide input field PI accepts input of the type (product name) of the sprayed pesticide. The pesticide input field PI may be a pull-down menu that allows selection from a plurality of pre-registered pesticides, or may be configured to display an input window PIW that accepts input of the name of the pesticide, as shown in FIG. 8B. When accepting input of the name, the first receiving unit 233 may display candidate pesticides during input, as shown in FIG. 8B.

[0054] The first receiving unit 233 may display effective pesticide candidates according to the type of disorder and the type of plant. The pesticide candidates are extracted, for example, from a list of pesticides that are applicable by law for the type of disorder (disease or type of pest) and the type of plant.

[0055] The spraying date input field DI accepts input of the date on which the pesticide was sprayed. Pressing the send button B1 sends the input contents of each field to the first reception unit 233. Pressing the cancel button B2 causes the pesticide input screen PR to disappear. The first reception unit 233 may display the date of the input day as the spraying date in the spraying date input field DI (i.e., may input the date in advance).

[0056] When the send button B1 is pressed and the pesticide application area, type of pesticide, and application date are received by the first reception unit 233, a display PD of the type of pesticide and the application date is added to the pest display area DP2, as shown in Fig. 7. In addition, the reception of input by the first reception unit 233 is emphasized by changing the color, size, or adding an icon to the countermeasure input button CB. Note that the countermeasure input button CB is not displayed in the disease display area DP1 in Fig. 5, but the countermeasure input button CB may be provided in the disease display area DP1.

[0057] <Recording unit 234> The recording unit 234 records the occurrence value together with the type of plant linked to the forecast value, the habitat linked to the user ID of the first user terminal 3, and the input date and time of the occurrence value. Specifically, the recording unit 234 records a record in which the type of plant, the type of disturbance, the habitat, the occurrence date and time, and the occurrence value are linked to one another. This record can be referenced from the first user terminal 3 or the second user terminal 4. Furthermore, by using this record as training data for the learning model used by the forecasting unit 232, the prediction accuracy of the forecasting unit 232 can be improved.

[0058] The recording unit 234 may record the habitat based on the location information transmitted from the first user terminal 3. This allows the second user to mainly record whether or not a disturbance has occurred in a habitat other than the habitat registered in the user data. Also, it is possible to record whether or not a disturbance has occurred without registering the habitat in the user data. Note that the location information is not limited to a combination of latitude and longitude obtained by GPS, for example, but may also be a representative value selected from map information (for example, the address of a farmland registered in a farmland map).

[0059] The recording unit 234 records, as the habitat included in the record, the managed habitat that is closest to the location information transmitted from the first user terminal 3, among the managed habitats registered in the user data by the registration unit 231. This saves the first user the trouble of inputting the habitat when recording the occurrence of a failure.

[0060] Furthermore, the recording unit 234 may record location information transmitted from the first user terminal 3 a certain number of times (for example, three times) or more as the habitat. This eliminates the need for the first user to input habitats other than those registered in the user data each time. Note that "location information transmitted a certain number of times or more" does not necessarily have to be location information that matches entirely, but also includes location information transmitted a certain number of times or more with a difference of the order of several meters. Also, for example, if the same farmland is entered multiple times on a farmland map, the address of this farmland will be the "location information transmitted a certain number of times or more."

[0061] The recording unit 234 also records the type of pesticide and the date of application, linking it to the obstacle. Specifically, the recording unit 234 records a record linking the type of plant, the type of obstacle, the habitat, the type of pesticide, and the date of application. This allows the first user to collect and record pesticide application status data without imposing an operational burden on the first user.

[0062] Furthermore, the recording unit 234 records, among the multiple types of failures, those for which pesticides are effective, linking them with the type of pesticide and the date of application. Specifically, if the type of pesticide input from the first user terminal 3 for a first failure is also effective for a second failure transmitted to the same first user terminal 3, the recording unit 234 records a first record linking the type of first plant that is the target of the first failure, the type of first failure, the habitat of the first plant, the type of pesticide, and the date of application, and another record linking the type of second plant that is the target of the second failure, the type of second failure, the habitat of the second plant, the type of pesticide, and the date of application. The type of pesticide and the date of application in the first record are the same as those in the second record. As a result, inputting one pesticide application data record pesticide application data for multiple failures, significantly reducing the input effort of the first user.

[0063] For example, in Figure 6, when spraying of pesticide A is input using the countermeasure input button CB in the pest display area DP2 for "cutworm," if this pesticide A is also effective against "aphids," the spraying of pesticide A is linked and recorded to both "cutworms" and "aphids." In addition to the countermeasure input button CB in the pest display area DP2 for "cutworms," ​​the countermeasure input button CB in the pest display area DP2 for "aphids" also changes to display "Countermeasure Completed" as shown in Figure 7. The recording unit 234 refers to a database (table) prepared in advance to determine the problems for which each pesticide is effective.

[0064] The first receiving unit 233 may use the database to estimate the type of plant being grown in the habitat from the type of pesticide that has been input, thereby eliminating the need for the first user to manually register a new plant when the first user starts growing the plant.

[0065] <History Output Unit 235> The history output unit 235 outputs the history of the recorded occurrence values ​​to the first user terminal 3. Specifically, the history output unit 235 causes the first user terminal 3 to display a list of occurrences of failures for each type of failure. This makes it easy for the first user to understand the history of failure occurrences in his / her own habitat. Furthermore, by displaying the history on the second user terminal 4 with permission from the first user, it also becomes easy for the second user to understand the history of failure occurrences in the habitat that he / she is instructing.

[0066] 9 is an example of a history screen HD displayed on the first user terminal 3. The history screen HD displays, for each type of problem, the name BT of the problem that has occurred in the past in the habitat managed by the first user, the type of plant ST, the date of occurrence CT, and the location LT of the problem. Note that while only one problem is illustrated in FIG. 9, if multiple problems have occurred in the habitat managed by the first user, multiple problems will be displayed. Note that the location LT of occurrence displays the nickname (label) of the habitat. The nickname of the habitat can be set arbitrarily by the first user.

[0067] The history output unit 235 may display the history on a map or a calendar. The history output unit 235 may also output history narrowed down by type of obstacle, type of plant, habitat, etc.

[0068] In addition, the history output unit 235 outputs the fault occurrence history including that of other users to the first user terminal 3. Fig. 10 is an example of a map screen MD displayed on the first user terminal 3. The map screen MD displays a map, fault information HI, and a fault occurrence icon NI. The fault information HI displays the habitat of the first user, the type of fault, and the type of plant. The fault information HI is displayed when the fault occurrence icon NI is pressed. The fault occurrence icon NI is displayed superimposed on the habitat where the fault occurred (including habitats managed by users other than the first user). The fault occurrence icon NI indicates the number of faults that have occurred.

[0069] Any fault occurrence history (fault occurrence icon NI) is displayed on the map screen MD by narrowing down the fault type and plant type on the first user terminal 3. Furthermore, the history output unit 235 may display only the fault occurrence icon NI corresponding to the fault that occurred during a period specified by the first user terminal 3.

[0070] The map screen MD may be displayed by dividing the entire map into, for example, 1 km meshes, with each section color-coded according to whether or not a fault has occurred, or the number of faults. This protects the privacy of users (farmers).

[0071] <Remind Unit 236> The reminder unit 236 sends a pesticide spray reminder to the first user terminal 3 when a predetermined number of days have passed since the pesticide was sprayed. The "predetermined number of days" is predetermined for each type of pesticide. The "remind" includes, for example, the target growing area, the type of pesticide, and the scheduled spraying date (or the number of days since the pesticide was sprayed). This prevents forgetting to spray pesticides and simplifies the first user's management of pesticide spraying schedules. The content of the reminder may be, for example, "XX days have passed since the spraying of pesticide A." The first user may spray a different pesticide than the one sprayed last time to avoid a reduction in the effectiveness of the pesticide due to resistance. The above-mentioned reminder allows the first user to check the pesticide sprayed last time.

[0072] <Second Receiving Unit 237> The second receiving unit 237 receives sharing permission for the second user terminal 4 from the first user terminal 3. Specifically, the second receiving unit 237 receives input of the user ID of the second user who is permitted to share the history of failure occurrences, etc., from the first user terminal 3. The first user inputs permission settings on the first user terminal 3 in response to the search results for the user ID or a permission request from the second user.

[0073] <Sharing Unit 238> The sharing unit 238 transmits the recorded occurrence values ​​to a second user terminal 4 that has been granted permission to share. Specifically, upon receiving a sharing request from the second user terminal 4, the sharing unit 238 displays data such as the occurrence values ​​transmitted and recorded from the first user terminal 3 (i.e., a record of the occurrence of a failure) on the second user terminal 4. This allows the second user who provides guidance to the first user to appropriately grasp the history of the failure, thereby improving the effectiveness of guidance by the second user.

[0074] Furthermore, the sharing unit 238 may cause the generated value to be displayed on the second user terminal 4 by push notification. In this case, the second accepting unit 237 accepts permission for the push notification to the second user terminal 4 from the first user terminal 3 as “sharing permission.”

[0075] Furthermore, the sharing unit 238 notifies the second user terminal 4 of the input of an occurrence value indicating the occurrence of a fault from the first user terminal 3. Specifically, when the first receiving unit 233 receives an input of "a fault has occurred" from the first user terminal 3, the sharing unit 238 transmits a message to the second user terminal 4 indicating that a fault has occurred at the first user. At this time, the type of plant, the type of fault, the habitat, etc. are also transmitted. This enables the second user to immediately provide instructions on how to respond.

[0076] 3. Fault Management Method This section describes a fault management method for the information processing device 2. This fault management method is executed by a computer with each unit of the information processing device 2 acting as each step.

[0077] Specifically, this fault management method includes a forecasting step, a first receiving step, and a recording step. In the forecasting step, a probability of a fault occurring in a plant is transmitted as a forecast value to a first user terminal 3. In the first receiving step, an input of an occurrence value indicating whether or not a fault has occurred is received from the first user terminal 3 to which the forecast value has been transmitted. In the recording step, the occurrence value is recorded together with the type of plant linked to the forecast value, the habitat linked to the user ID of the first user terminal 3, and the date and time when the occurrence value was input.

[0078] 11 is an activity diagram showing the flow of information processing (processing for recording a failure occurrence) executed by the failure management system 1. The information processing will be described below along with each activity in this activity diagram.

[0079] The fault occurrence recording process starts with the processor 23 of the information processing device 2 predicting a forecast value (activity A110). At this time, the processor 23 stores the predicted forecast value in the storage unit 22. The processor 23 transmits the predicted forecast value to the first user terminal 3 via the communication unit 21 (activity A120). The information processing device 2 transmits at least one required forecast value to each of the multiple first user terminals 3 based on the user data of each first user terminal 3.

[0080] Next, the processor 33 of the first user terminal 3 receives the forecast value from the information processing device 2 via the communication unit 31 (activity A130). After receiving the forecast value, the processor 33 displays the forecast value on the display unit 34, for example, as shown in the forecast screen BD1 or BD2 in FIG. 5 or 6 (activity A140). After displaying the forecast value, the processor 33 accepts input from the input unit 35 indicating whether or not the fault for which the forecast value was transmitted has occurred (occurrence value) (activity A150). After inputting the occurrence value, the processor 33 transmits the input occurrence value to the information processing device 2 via the communication unit 31, together with the type of fault, the type of plant, and its habitat (activity A160).

[0081] Next, the processor 23 of the information processing device 2 receives data such as the generation value from the first user terminal 3 via the communication unit 21 (activity A170). After receiving the data, the processor 23 stores a record including the generation value, the type of disturbance, the type of plant, the habitat, and the input date and time of the generation value in the storage unit 22 (activity A180).

[0082] The records stored in the storage unit 22 are transmitted from the communication unit 21 to the first user terminal 3 or the second user terminal 4 in response to a request from the first user terminal 3 or the second user terminal 4 .

[0083] 4. Operation The operation of this embodiment can be summarized as follows: By inputting a response to the forecast value transmitted to the first user terminal 3, the occurrence or non-occurrence of a fault can be easily registered along with the type of plant, its habitat, and the date and time of the fault. This makes it easy to manage the occurrence of faults.

[0084] In particular, the first user can register the above information with a single tap or two taps including a confirmation operation. Furthermore, since only the minimum necessary information is registered, communication costs can be reduced.

[0085] Although the embodiment of the present invention has been described above, the present invention is not limited to this and can be modified as appropriate within the scope of the technical idea of ​​the invention.

[0086] 5. Others In the above embodiment, the information processing device 2 performs various storage and control operations, but multiple external devices may be used instead of the information processing device 2. In other words, various information and programs may be distributed and stored in multiple external devices using blockchain technology or the like.

[0087] The aspect of the present embodiment is not limited to the fault management system 1, and may be a fault management method or a program. The fault management method includes the steps of the fault management system 1. The program causes a computer to function as the fault management system 1.

[0088] The forecasting unit 232 does not necessarily need to use a learning model, that is, the forecasting unit 232 may predict the forecast value using an algorithm constructed by a statistical method other than machine learning.

[0089] It may be provided in the following manner.

[0090] (1) A fault management system comprising a processor, the processor being configured to execute a forecasting step, a first receiving step, and a recording step, wherein in the forecasting step, a possibility of a fault occurring in a plant is transmitted to a first user terminal as a forecast value, in the first receiving step, an input of an occurrence value indicating whether or not the fault for which the forecast value was transmitted has occurred is received from the first user terminal, and in the recording step, the occurrence value is recorded together with a type of plant linked to the forecast value, a habitat linked to a user ID of the first user terminal, and the date and time when the occurrence value was input.

[0091] (2) In the fault management system described in (1) above, in the first reception step, the input of the generated value is received by a single action or a double action from a state in which the forecast value is displayed on the first user terminal.

[0092] (3) In the fault management system described in (1) or (2) above, in the recording step, the habitat is recorded based on location information transmitted from the first user terminal.

[0093] (4) In the fault management system described in (3) above, the processor is further configured to execute a registration step, in which user data including the user ID and managed habitat is registered in the registration step, and in the recording step, the managed habitat registered in the user data that is closest to the location information is recorded as the habitat.

[0094] (5) In the fault management system described in (3) above, in the recording step, the location information transmitted from the first user terminal a certain number of times or more is recorded as the habitat.

[0095] (6) In the fault management system described in any one of (1) to (5) above, the processor is further configured to execute a history output step, in which the history output step outputs the history of the recorded occurrence values ​​to the first user terminal.

[0096] (7) In the fault management system described in any one of (1) to (6) above, in the first reception step, input of the type and date of spraying of the pesticide sprayed in response to the fault for which the forecast value was sent is received from the first user terminal, and in the recording step, the type and date of spraying of the pesticide are recorded in association with the fault.

[0097] (8) In the fault management system described in (7) above, in the forecasting step, the probability of each of multiple types of faults occurring in plants is sent to the first user terminal as the forecast value, and in the recording step, of the multiple types of faults, faults for which the pesticide is effective are recorded in association with the type of pesticide and the date of spraying.

[0098] (9) In the fault management system described in (7) or (8) above, the processor is configured to further execute a reminding step, in which a reminder for pesticide spraying is sent to the first user terminal when a predetermined number of days have passed since the date of spraying the pesticide.

[0099] (10) In the fault management system described in any one of (1) to (9) above, the processor is further configured to execute a second reception step and a sharing step, in which the second reception step receives sharing permission for a second user terminal from the first user terminal, and in the sharing step, transmits the recorded generation value to the second user terminal that has received the sharing permission.

[0100] (11) In the fault management system described in (10) above, in the sharing step, the input of the occurrence value indicating the occurrence of the fault from the first user terminal is notified to the second user terminal. Of course, this is not limited to the above.

[0101] Finally, while various embodiments of the present disclosure have been described, they are presented as examples and are not intended to limit the scope of the invention. The novel embodiments may be embodied in various other forms, and various omissions, substitutions, and modifications may be made without departing from the spirit of the invention. Such embodiments and modifications are intended to be included within the scope and spirit of the invention, as well as within the scope of the inventions and their equivalents as defined in the claims.

[0102] 1: Fault management system, 2: Information processing device, 3: First user terminal, 4: Second user terminal, 20: Communication bus, 21: Communication unit, 22: Memory unit, 23: Processor, 30: Communication bus, 31: Communication unit, 32: Memory unit, 33: Processor, 34: Display unit, 35: Input unit, 40: Communication bus, 41: Communication unit, 42: Memory unit, 43: Processor, 44: Display unit, 45: Input unit, 231: Registration unit, 232: Forecast unit, 233: First reception unit, 234: Recording unit, 235: History output unit, 236: Remind unit, 237: Second reception unit, 238: Sharing unit

Claims

1. A fault management system comprising a processor, the processor being configured to execute a forecasting step, a first receiving step, and a recording step, wherein in the forecasting step, a possibility of a fault occurring in a plant is transmitted to a first user terminal as a forecast value, in the first receiving step, an input of an occurrence value indicating whether or not the fault for which the forecast value was transmitted has occurred is received from the first user terminal, and in the recording step, the occurrence value is recorded together with a type of plant linked to the forecast value, a habitat linked to a user ID of the first user terminal, and the date and time when the occurrence value was input.

2. A fault management system as claimed in claim 1, wherein in the first reception step, input of the occurring value is received by a single action or a double action from a state in which the forecast value is displayed on the first user terminal.

3. A fault management system as claimed in claim 1 or 2, wherein in the recording step, the habitat is recorded based on location information transmitted from the first user terminal.

4. A fault management system as described in claim 3, wherein the processor is further configured to execute a registration step, in which user data including the user ID and a managed habitat is registered in the registration step, and in which the recording step records as the habitat the managed habitat registered in the user data that is closest to the location information.

5. A fault management system as claimed in claim 3, wherein in the recording step, the location information transmitted from the first user terminal a certain number of times or more is recorded as the habitat.

6. A fault management system as claimed in any one of claims 1 to 5, wherein the processor is further configured to execute a history output step, in which the history output step outputs the history of the recorded occurrence values ​​to the first user terminal.

7. A fault management system as claimed in any one of claims 1 to 6, wherein in the first receiving step, input of the type and date of spraying of the pesticide sprayed in response to the fault for which the forecast value was transmitted is received from the first user terminal, and in the recording step, the type and date of spraying of the pesticide are recorded in association with the fault.

8. A fault management system as described in claim 7, wherein in the forecasting step, the probability of each of a plurality of types of faults occurring in plants being generated is transmitted to the first user terminal as the forecast value, and in the recording step, among the plurality of types of faults, faults for which the pesticide is effective are recorded in association with the type of pesticide and the date of application.

9. A fault management system as described in claim 7 or claim 8, wherein the processor is further configured to execute a reminding step, in which a reminder for pesticide spraying is sent to the first user terminal when a predetermined number of days have passed since the date of spraying of the pesticide.

10. A fault management system as claimed in any one of claims 1 to 9, wherein the processor is further configured to execute a second reception step and a sharing step, wherein in the second reception step, a sharing permission for a second user terminal is received from the first user terminal, and in the sharing step, the recorded occurrence value is transmitted to the second user terminal that has received the sharing permission.

11. A fault management system according to claim 10, wherein in the sharing step, the input of the occurrence value indicating the occurrence of the fault from the first user terminal is notified to the second user terminal.

Images