JP6024126B2 - Failure response support apparatus, failure response support system, failure response support method, and failure response support program - Google Patents

Description

  The present invention relates to a failure response support apparatus, a failure response support system, a failure response support method, and a failure response support program.

  2. Description of the Related Art Conventionally, a system for remotely monitoring a device via a network (hereinafter referred to as a “remote monitoring system”) has been constructed for the purpose of improving the efficiency of maintenance work related to the device such as an image forming apparatus (for example, a patent). Reference 1). According to the remote monitoring system, when an abnormal state or a prior state of abnormality is detected in the device, the device state information at that time is automatically transferred to the server. A call center operator or maintenance staff performs maintenance work based on the transferred information.

  On the other hand, some devices such as image forming apparatuses have an application platform. An application platform API (Application Program Interface) is open to the public, and application programs for devices are developed and sold by device manufacturers and software vendors. For example, the user can improve the efficiency of the business by installing an application program suitable for his / her business in the device.

  However, conventionally, what is monitored by the remote monitoring system has been mainly limited to the state related to the hardware of the device. In other words, the application program itself was not monitored.

  Therefore, it is necessary for the user to separately report a failure based on an operation error of the application program.

  However, application programs are developed by many software vendors. Therefore, the user has to determine the seller or manufacturer for each application program and request the seller or manufacturer to investigate.

  The present invention has been made in view of the above points, and an object of the present invention is to improve the efficiency of handling a failure related to a program in a device.

  Therefore, in order to solve the above-described problem, the failure handling support apparatus stores a receiving unit that receives failure information transmitted from a device, and a storage that stores identification information of a notification destination related to the failure of the program in association with the identification information of the program. A notification unit that specifies a notification unit of the program based on identification information of the program included in the failure information, and information for notifying the occurrence of the failure indicated by the failure information. A notification unit that transmits to a terminal related to the destination.

  This makes it possible to efficiently deal with failures related to programs in the device.

It is a figure which shows the structural example of the failure response assistance system in embodiment of this invention. It is a figure which shows the hardware structural example of the failure response assistance apparatus in embodiment of this invention. FIG. 2 is a diagram illustrating an example of a hardware configuration of a multifunction machine according to an embodiment of the present invention. 2 is a diagram illustrating a software configuration example of a multifunction peripheral according to an embodiment of the present invention. It is a figure which shows the function structural example of the failure response assistance apparatus and terminal in embodiment of this invention. FIG. 11 is a sequence diagram for explaining an example of a processing procedure of log information recording processing at a normal time in the multifunction peripheral. FIG. 10 is a sequence diagram for explaining an example of a processing procedure executed by the multifunction machine when a failure occurs. It is a sequence diagram for demonstrating an example of the process sequence which a failure response assistance apparatus performs according to reception of failure information. It is a figure which shows the structural example of a failure information storage part. It is a figure which shows the structural example of an application development information storage part. It is a sequence diagram for demonstrating an example of the process sequence of a failure response process. It is a figure which shows an example of an integrated development environment.

  Hereinafter, embodiments of the present invention will be described with reference to the drawings. FIG. 1 is a diagram illustrating a configuration example of a failure handling support system according to an embodiment of the present invention. In the failure support system 1 shown in FIG. 1, the device manufacturer environment E2 is connected to the development environment E3 and the user environment E1 via a network N1 such as the Internet.

  The device manufacturer environment E2 is, for example, a device that manufactures and sells a solution such as a multifunction device 10a, a printer 10b, and a projector 10c used in the user environment E1, and a conference system 10d (for example, a video conference system 10d). This is a system environment operated by a manufacturer. However, the device manufacturer environment E2 is not necessarily the system environment of the device manufacturer. It may be a system environment operated by a company operating a device application providing environment or a software house.

  In the present embodiment, the device manufacturer environment E2 includes a failure handling support apparatus 20. The failure support apparatus 20 is a service (hereinafter referred to as “failure support service”) for supporting a failure that has occurred in a device in the user environment E1, particularly, a developer's failure support for an application installed in the device. Is provided via the network N1. The failure handling support apparatus 20 may be configured by a single computer or may be configured by a plurality of computers distributed on a network. Further, the failure support service may be provided as a cloud service or the like.

  In this embodiment, the term developer is used for convenience, but the developer or the person in charge of development does not have to be actually developing. Any person who can be a notification destination of a failure in a device, such as a person in charge of a window or an administrator, may be used. Further, the developer or the person in charge of development may not be an individual. Usually, development of one application or failure handling is performed by a plurality of individuals or organizations. Therefore, the developer or the person in charge of development may be the entire development environment E3 (software vendor) or a contractor for development. Further, the developer or the person in charge of development does not necessarily have to be an organization that conducts development. It may be a call center or the like that accepts a failure related to a device.

  The user environment E1 is a system environment of users such as the multifunction machine 10a, the printer 10b, the projector 10c, and the conference system 10d. In the user environment E1, the multifunction machine 10a, the printer 10b, the projector 10c, the conference system 10d, and the like are connected via a network such as a LAN (Local Area Network).

  The development environment E3 is a system environment in a company (software vendor) that develops applications installed in devices. In the development environment E3, an application is developed using an API (Application Program Interface) published on an application platform mounted on the device. The development environment E3 includes one or more terminals 30 and the like. The terminal 30 is an information processing apparatus such as a PC (Personal Computer) used by an application developer.

  FIG. 2 is a diagram illustrating a hardware configuration example of the failure handling support apparatus according to the embodiment of the present invention. 2 includes a drive device 200, an auxiliary storage device 202, a memory device 203, a CPU 204, an interface device 205, and the like that are mutually connected by a bus B.

  A program that realizes processing in the failure handling support apparatus 20 is provided by a recording medium 201 such as a CD-ROM. When the recording medium 201 storing the program is set in the drive device 200, the program is installed from the recording medium 201 to the auxiliary storage device 202 via the drive device 200. However, it is not always necessary to install the program from the recording medium 201, and the program may be downloaded from another computer via a network. The auxiliary storage device 202 stores the installed program and stores necessary files and data.

  The memory device 203 reads the program from the auxiliary storage device 202 and stores it when there is an instruction to start the program. The CPU 204 executes a function related to the failure handling support apparatus 20 in accordance with a program stored in the memory device 203. The interface device 205 is used as an interface for connecting to a network.

  FIG. 3 is a diagram illustrating a hardware configuration example of the multifunction peripheral according to the embodiment of the present invention. In FIG. 3, the multifunction machine 10 a includes hardware such as a controller 11, a scanner 12, a printer 13, a modem 14, an operation panel 15, a network interface 16, and an SD card slot 17.

  The controller 11 includes a CPU 111, a RAM 112, a ROM 113, an HDD 114, an NVRAM 115, and the like. The ROM 113 stores various programs and data used by the programs. The RAM 112 is used as a storage area for loading a program, a work area for the loaded program, and the like. The CPU 111 realizes various functions by processing a program loaded in the RAM 112. The HDD 114 stores a program and various data used by the program. The NVRAM 115 stores various setting information and the like.

  The scanner 12 is hardware (image reading means) for reading image data from a document. The printer 13 is hardware (printing means) for printing print data on printing paper. The modem 14 is hardware for connecting to a telephone line, and is used to execute transmission / reception of image data by FAX communication. The operation panel 15 is hardware including input means such as buttons for accepting input from the user, display means such as a liquid crystal panel, and the like. The liquid crystal panel may have a touch panel function. In this case, the liquid crystal panel also functions as an input unit. The network interface 16 is hardware for connecting to a network such as a LAN (whether wired or wireless). The SD card slot 17 is used for reading a program stored in the SD card 80. That is, in the multifunction machine 10a, not only the program stored in the ROM 113 but also the program stored in the SD card 80 can be loaded into the RAM 112 and executed. The SD card 80 may be replaced by another recording medium (for example, a CD-ROM or a USB (Universal Serial Bus) memory). That is, the type of recording medium corresponding to the positioning of the SD card 80 is not limited to a predetermined one. In this case, the SD card slot 17 may be replaced by hardware corresponding to the type of recording medium.

  FIG. 4 is a diagram illustrating a software configuration example of the multifunction machine according to the embodiment of the present invention. In FIG. 4, the multifunction machine 10 a includes a device control unit 121, an application platform 122, and one or more applications 123. The device control unit 121 controls the hardware of the multifunction machine 10a. The device control unit 121 may include an OS (Operating System).

  The application platform 122 provides an API in the form of, for example, a method or a function to the application 123 installed in the multifunction peripheral 10a, and causes the multifunction peripheral 10a to execute processing according to the API call. The application platform 122 also manages the life cycle of the application 123, such as installing and uninstalling the application 123, starting and stopping the installed application 123, and the like. However, the components of the application platform 122 shown in FIG. 4 are mainly limited to those involved in transmission of failure information, which is information related to a failure that has occurred in the multifunction peripheral 10a.

  4, the application platform 122 includes a device event receiving unit 131, a device information acquiring unit 132, an operation event receiving unit 133, an application management unit 134, a platform management unit 135, a log management unit 136, and a failure information transmission unit 137. Etc.

  The device event receiving unit 131 is information (hereinafter referred to as an event) detected by the device control unit 121, such as a change in setting information managed by the device control unit 121, a user login to or logout from the multifunction peripheral 10a. , Referred to as “device event information”) from the device control unit 121. The device event receiving unit 131 notifies the log management unit 136 of the received device event information.

  The device information acquisition unit 132 includes, for example, the device control unit 121 including unique information of the multifunction device 10a, hardware configuration information and software configuration information of the multifunction device 10a, and various setting information for the multifunction device 10a. It is acquired from the RAM 112, ROM 113, HDD 114, NVRAM 115, etc. via the interface (API). The unique information of the multifunction machine 10a is, for example, identification information (hereinafter referred to as “machine number”) of the machine body of the multifunction machine 10a. The hardware configuration information of the multifunction device 10a includes, for example, model information indicating the model of the multifunction device 10a, information indicating peripheral devices installed in the multifunction device 10a, and the like. The configuration information of the software of the multifunction device 10a includes version information of the application platform 122, a list of identification information (which may include version information) of applications and various software installed in the multifunction device 10a, and the like. Including. Hereinafter, the information acquired by the device information acquisition unit 132 is referred to as “device information”. The device information acquisition unit 132 notifies the log management unit 136 of the acquired device information.

  The operation event reception unit 133 receives an event indicating an operation instruction or the like input by the user via the operation panel 15 from the operation panel 15. The operation event receiving unit 133 notifies the log management unit 136 of information indicating the received event (hereinafter referred to as “operation event information”).

  The application management unit 134 is generated for each application 123, and manages and monitors the state of the corresponding application 123. For example, the application management unit 134 starts and stops the application 123. In addition, the application management unit 134 acquires information indicating the state of the application 123 (hereinafter referred to as “application state information”) from the application 123. The information indicating the state of the application 123 may include, for example, identification information (for example, a method name and a step number) of processing being executed by the application 123, values of various variables used by the application 123, and the like. . The application management unit 134 also detects an abnormal state of the application 123. The detection of the abnormal state is performed by, for example, detecting the occurrence of an exception in the application 123 or notifying error information from the application 123. Error information will also be described as an example of application state information. The application management unit 134 notifies the log management unit 136 of the acquired application state information. The application state information includes identification information (hereinafter referred to as “application ID”) of the application 123 related to the application state information. Note that one common application management unit 134 for a plurality of applications 123 may be realized.

  The platform management unit 135 notifies the log management unit 136 of information indicating the state of the application platform 122 (hereinafter referred to as “platform information”). The information indicating the state of the application platform 122 includes, for example, identification information (for example, a method name and a step number) of processing being executed by the application platform 122, values of various variables used by the application platform 122, and the like. May be.

  The log management unit 136 stores information notified from each unit in the log storage unit 124. For example, the log storage unit 124 stores the history for the past N times for each piece of information. The value of N may be different for each type of information. Hereinafter, the information stored in the log storage unit 124 is referred to as “log information”. The log storage unit 124 can be realized using, for example, the HDD 114 or a storage device connected to the multifunction machine 10a via a network.

  The failure information transmission unit 137 transmits failure information including log information and the like stored in the log storage unit 124 to the failure handling support apparatus 20 when occurrence of a failure is detected in the multifunction machine 10a.

  The application 123 is a program that is developed using an API provided by the application platform 122 and is installed in the multifunction peripheral 10a.

  FIG. 5 is a diagram illustrating a functional configuration example of the failure handling support apparatus and the terminal according to the embodiment of the present invention.

  In FIG. 5, the failure handling support apparatus 20 includes a failure information receiving unit 211, a person-in-charge identification unit 212, a failure notification unit 213, a front end unit 214, an authentication unit 215, an evaluation environment construction unit 216, an automatic evaluation unit 217, and the like. Have. Each of these units is realized by processing executed by the CPU 204 by a program installed in the failure support apparatus 20. However, each unit may be distributed over a plurality of computers.

  The failure handling support apparatus 20 also uses a failure information storage unit 221, an application development information storage unit 222, an authentication information storage unit 223, a module storage unit 224, and the like. Each of these storage units can be realized using, for example, the auxiliary storage device 202 or a storage device connected to the failure support apparatus 20 via a network.

  The failure information receiving unit 211 receives failure information transmitted from the multifunction peripheral 10a that has detected the occurrence of a failure in the user environment E1. The failure information receiving unit 211 stores the received failure information in the failure information storage unit 221.

  The person-in-charge identifying unit 212 refers to the failure information received by the failure information receiving unit 211, the application development information storage unit 222, and the like, and develops the application 123 that is presumed to be the cause of the failure related to the failure information. Identify the developer (developer) in charge of The person-in-charge specifying unit 212 associates the identification information of the specified developer in charge with the failure information stored in the failure information storage unit 221.

  That is, the failure information includes, for example, identification information of the application 123 that has caused the multifunction peripheral 10a to execute processing when the failure occurs, or the application 123 that was in an abnormal state when the failure occurred. Further, the application development information storage unit 222 stores, for each identification information of the application 123, identification information of a person in charge of development, a contact address (for example, an e-mail address) and the like.

  However, information regarding the person in charge of development of the application 123 (hereinafter referred to as “person in charge information”) may be attached to the application 123 when the application 123 is distributed (at the time of sale). In this case, the person-in-charge information may be stored in the HDD 114 or the NVRAM 115 of the multifunction machine 10a as the application 123 is installed in the multifunction machine 10a. When the person-in-charge information of the application 123 is stored in the multifunction peripheral 10a together with the application 123, the trouble information transmitted from the multifunction peripheral 10a may include person-in-charge information. When such a form is adopted, the person-in-charge specifying unit 212 may specify a person in charge of development based on the person-in-charge information included in the failure information.

  The failure notification unit 213 notifies the development person specified by the person-in-charge specifying unit 212 of the occurrence of the failure. The occurrence of a failure is notified by e-mail, for example. Hereinafter, the e-mail notifying the occurrence of the failure is referred to as “notification mail”. The notification mail includes, for example, link information (URL (Uniform Resource Locator)) to the failure support service. If the identified developer is not an individual, the notification mail is transmitted to the representative mail address of the development environment E3, for example. In such a case, a notification mail may be transferred to each person in charge of development in the development environment E3.

  The front end unit 214 provides a GUI (Graphical User Interface) of a failure support service. In the present embodiment, the GUI is composed of HTML data described in HTML (HyperText Markup Language). However, the GUI may be configured by a data format other than HTML data.

  The authentication unit 215 performs authentication of a user who requests use of the failure support service. Specifically, in the present embodiment, the person in charge of development who has received the notification mail becomes a user of the failure support service. Therefore, the authentication unit 215 performs authentication of the developer in charge by checking the authentication information (for example, the user name and password) input at the terminal 30 with the authentication information stored in the authentication information storage unit 223. To do. The authentication information storage unit 223 stores authentication information of each user (developer) who has a contract for using the failure support service.

  The evaluation environment construction unit 216 reproduces the trouble in question and evaluates the environment for evaluating the operation of the application 123 estimated to be the cause of the trouble (hereinafter referred to as “evaluation environment 250”). Build (generate). The evaluation environment 250 is a virtual environment that imitates or has a hardware configuration, a software configuration, or the like that is the same as or substantially the same as that of the MFP 10a in which a failure has occurred. The expression “virtual environment” is not an environment constructed using the actual multifunction device 10a, but an environment in which the hardware configuration and software configuration similar to those of the multifunction device 10a are reproduced virtually (in software). Based.

  As shown in FIG. 5, the evaluation environment 250 includes a hardware imitation unit 251 and a platform imitation unit 252. The hardware imitation unit 251 imitates the hardware of the multifunction machine 10a. The hardware imitation unit 251 may be capable of imitating the hardware of the multifunction machine 10a on the surface. That is, the hardware imitation unit 251 provides an interface similar to that of the hardware of the multifunction peripheral 10a, and the operation corresponding to the calling of the interface may be a dummy. The platform imitation unit 252 may be realized by the same program group as the application platform 122, or the same program group as the application platform 122 is realized by a program group modified for operation on the hardware imitation unit 251. May be. That is, the platform imitation unit 252 imitates the actual application platform 122 not only on the surface behavior but also on the internal logic.

  The failure support apparatus 20 includes, for example, a program that causes a computer to function as the hardware imitation unit 251 (hereinafter, referred to as “hardware imitation program”) for each model of the multifunction peripheral 10a. Or the said program is one, and the difference according to a model may be made into the setting information with respect to the said program. Further, the failure support apparatus 20 has, for example, a program (hereinafter referred to as “platform imitation program”) that causes the computer to function as the platform imitation unit 252 corresponding to the version for each version of the application platform 122. The platform imitation unit 252 selects a hardware imitation program corresponding to the model of the MFP 10a that is the transmission source of the failure information, and a platform imitation program corresponding to the version of the application platform 122 of the MFP 10a, and selects these programs. By starting, the evaluation environment 250 is generated. The hardware imitation program and the platform imitation program may be generally realized by software called an emulator or a simulator.

  The evaluation environment construction unit 216 further includes a hardware imitation unit 251 corresponding to the model of the MFP 10a that is the transmission source of the fault information, a platform imitation unit 252 corresponding to the version of the application platform 122 included in the MFP 10a, and the like. For the combined evaluation environment 250, the same application 123 as the application 123 installed in the multifunction machine 10a is installed. The installed application 123 is stored in the module storage unit 224. The module storage unit 224 stores the entity (program module) of each application 123 that has been sold so far and is in the maintenance period.

  Note that the location where the evaluation environment 250 is constructed (where the hardware imitation program and the platform imitation program are activated) may not be the failure support apparatus 20. It may be a computer connected to the failure support apparatus 20 via a network. Alternatively, a virtual machine may be operated on the failure support apparatus 20 or the computer, and the evaluation environment 250 may be constructed on one of the virtual machines.

  The automatic evaluation unit 217 executes processing for reproducing a failure in the evaluation environment 250. Specifically, the automatic evaluation unit 217 generates an operation event in the evaluation environment 250 similar to the operation performed in the multifunction device 10a in which the failure has occurred based on the history of operation events included in the failure information. Let

  On the other hand, the terminal 30 includes a UI unit 31. In the present embodiment, the UI unit 31 is a Web browser.

  Hereinafter, a processing procedure executed in the failure support system 1 will be described. FIG. 6 is a sequence diagram for explaining an example of a processing procedure of log information recording processing in a normal state in the multifunction peripheral. In FIG. 6, the interface unit 130 represents the device event receiving unit 131, the device information acquiring unit 132, the operation event receiving unit 133, the application management unit 134, and the platform management unit 135 in FIG.

  For example, when device event information is notified from the device control unit 121 to the device event receiving unit 131 (S101), the device event receiving unit 131 notifies the log management unit 136 of the device event information (S102). The log management unit 136 adds the newly notified device event information to the device event information history stored in the log storage unit 124.

  When the user performs an operation via the operation panel 15, the operation panel 15 transmits an event indicating the operation to the operation event receiving unit 133 (S103). The operation event receiving unit 133 notifies the log management unit 136 of operation event information indicating the event (S104). The log management unit 136 adds the newly notified operation event information to the operation event information history stored in the log storage unit 124.

  Note that steps S101 and S102, and S103 and S104 are performed irregularly.

  Each application management part 134 acquires application state information from the application 123 corresponding to each regularly, for example (S105, S106). The application management unit 134 notifies the acquired application state information to the log management unit 136 (S107). The log management unit 136 adds the newly notified application state information to the application state information history stored in the log storage unit 124 for each application 123 (for each application ID).

  For example, the device information acquisition unit 132 periodically acquires device information via the device control unit 121 (S108, S109). The device information acquisition unit 132 notifies the log management unit 136 of the acquired device information (S110). The log management unit 136 adds the newly notified device information to the device information history stored in the log storage unit 124.

  For example, the platform management unit 135 periodically acquires platform information (S111). The platform management unit 135 notifies the log management unit 136 of the acquired platform information (S112). The log management unit 136 adds the newly notified platform information to the platform information history stored in the log storage unit 124.

  For example, the log management unit 136 may periodically transfer the log information stored in the log storage unit 124 to the failure support apparatus 20. The transferred log information may be deleted from the log storage unit 124.

  Next, an example of a processing procedure executed by the multifunction machine 10a when a failure occurs in the multifunction machine 10a will be described. FIG. 7 is a sequence diagram for explaining an example of a processing procedure executed by the multifunction device when a failure occurs.

  When detecting the occurrence of a failure, the failure information transmission unit 137 requests the log management unit 136 to acquire log information (S121). The occurrence of a failure is detected based on, for example, notification of information (hereinafter referred to as “error information”) indicating the occurrence of an abnormality from the device event receiving unit 131, the application management unit 134, the platform management unit 135, or the like. . That is, when an abnormality occurs in the corresponding application 123 or application platform 122, the application management unit 134 and the platform management unit 135 indicate the application ID of the application 123 in which an abnormality has occurred or the application ID of the application platform 122, and the content of the abnormality. Error information including information indicating (phenomenon) is notified to the failure information transmission unit 137.

  In response to the request from the failure information transmission unit 137, the log management unit 136 requests each application management unit 134, device information acquisition unit 132, platform management unit 135, and the like to acquire log information (S122).

  Each application management unit 134 acquires application state information from the corresponding application 123 in response to a request from the log management unit 136 (S123, S124). Each application management unit 134 notifies the log management unit 136 of the acquired application state information (S125).

  In response to a request from the log management unit 136, the device information acquisition unit 132 acquires device information via the device control unit 121 (S126, S127). The device information acquisition unit 132 notifies the acquired device information to the log management unit 136 (S128).

  The platform management unit 135 acquires platform information in response to a request from the log management unit 136 (S129). The platform management unit 135 notifies the log management unit 136 of the acquired platform information (S130).

  The log management unit 136 stores the log information notified from the log information acquisition request destination in the log storage unit 124. The log information stored here may be distinguishable from other histories as log information when a failure occurs.

  When the log information is notified from all the log information acquisition request destinations, the log management unit 136 notifies the failure information transmission unit 137 of the completion of the acquisition of the log information (S131). Subsequently, the failure information transmitting unit 137 transmits the failure information including the log information stored in the log storage unit 124 to the log information receiving unit of the failure handling support apparatus 20 (S132). The failure information includes, for example, error information in addition to log information. By transmitting the failure information, the failure handling support apparatus 20 is notified of the occurrence of a failure in the multifunction machine 10a. Note that the log information included in the failure information includes not only the log information acquired in response to the occurrence of the failure but also log information related to the history stored in the log storage unit 124 by the processing described in FIG. Is desirable.

  Subsequently, an example of a processing procedure executed by the failure handling support apparatus 20 in response to reception of failure information will be described. FIG. 8 is a sequence diagram for explaining an example of a processing procedure executed by the failure support apparatus in response to reception of failure information. In FIG. 8, the same steps as those in FIG.

  When receiving the failure information (S132), the failure information receiving unit 211 stores the received failure information in the failure information storage unit 221 (S201).

  FIG. 9 is a diagram illustrating a configuration example of the failure information storage unit. In FIG. 9, the record stored in the failure information storage unit 221 includes items such as a failure ID, failure information, status, and a developer name. One record is generated in response to one failure information reception.

  The failure ID is identification information of each failure information. The failure ID is given by the failure information receiving unit 211 when the failure information is stored in the failure information storage unit 221, for example.

  The failure information is the received failure information. In FIG. 9, in the failure information, the machine number of the MFP 10a that is the transmission source of the failure information, error information, device information history, application status information history, platform information history, operation event information history, device Indicates that the event information history is included. The status is a status of work for a failure related to the failure information. For example, when failure information is stored in the failure information storage unit 221, “unsupported” is stored as an initial value. The name of the person in charge of development is an identification name of the person in charge of developing the application 123 that is highly likely to be the cause of the failure related to the failure information. When failure information is stored in the failure information storage unit 221, the item of the person in charge of development is empty.

  Subsequently, the failure information receiving unit 211 specifies the failure ID of the received failure information, and identifies the person in charge of developing the application 123 estimated to be the cause of the failure related to the failure information. Request to the unit 212 (S202). The person-in-charge specifying unit 212 specifies a person in charge of development based on the application ID included in the error information of the failure information and the application development information storage unit 222 (S203).

  FIG. 10 is a diagram illustrating a configuration example of the application development information storage unit. In FIG. 10, the application development information storage unit 222 stores information related to the developer in charge, such as the name of the developer in charge and the mail address, for each application ID (for each application 123). That is, the application development information storage unit 222 stores correspondence information between the application 123 and the person in charge of development. In the present embodiment, the application ID is not identification information for each individual (each copy) of the application 123 but identification information corresponding to the name of the application 123. Specifically, each application 123 named “AAA” has the same application ID.

  In step S203, the person-in-charge identification unit 212 acquires the name of the person in charge of development and the mail address stored in the application development information storage unit 222 in association with the application ID included in the error information of the failure information. .

  Subsequently, the person-in-charge identification unit 212 associates the development person name identified in step S203 with the failure information related to the failure ID specified in the identification request of the development person (S204). Specifically, in the failure information storage unit 221, the name of the developer in charge identified in step S203 is stored in the item of the name of the developer in charge of the record in which the failure information is stored.

  Subsequently, the person-in-charge specifying unit 212 requests the failure notification unit 213 to notify the development person in charge of the occurrence of the failure (S205). In the request, for example, the failure ID and the e-mail address of the developer in charge identified in step S203 are specified.

  Subsequently, the failure notification unit 213 transmits a notification mail to the designated mail address (S206). In the notification mail, an application ID included in the error information of the failure information, a message indicating that a failure may have occurred due to the application 123 related to the application ID, and the like are specified. The notification mail also includes link information (URL (Uniform Resource Locator)) to the failure support service. The failure notification unit 213 may change the status value in the failure information storage unit 221 to, for example, “notified” when the notification mail is transmitted normally. “Notified” indicates a state in which a development person has been notified of the occurrence of a failure.

  When the notification mail is viewed on the terminal 30 of the development environment E3 that is the transmission destination of the notification mail, the development staff can recognize the occurrence of the failure.

  Next, an example of a processing procedure that is executed in response to browsing of the notification mail will be described. FIG. 11 is a sequence diagram for explaining an example of the processing procedure of the failure handling processing.

  For example, when link information in the notification mail displayed on the terminal 30 is clicked by the developer, the UI unit 31 transmits an access request to the URL indicated by the clicked link information (S301). When the access request is received in the failure support apparatus 20, the front end unit 214 returns HTML data including screen information of the login screen (hereinafter referred to as “login screen data”) to the access request source ( S302). In the present embodiment, an example in which screen information is described or defined in HTML will be described. However, the screen information may be described or defined in other formats.

  The UI unit 31 displays a login screen on the terminal 30 based on the returned login screen data. The developer in charge inputs, for example, a user name and a password on the login screen. The UI unit 31 transmits a login request specifying the input user name and password to a destination defined in the login screen data (S303).

  When the front-end unit 214 receives the login request, the front-end unit 214 requests the authentication unit 215 to authenticate the user name and password specified in the login request (S304). The authentication unit 215 performs authentication processing by comparing the user name and password with the user name and password stored in the authentication information storage unit 223. If the authentication is successful, the authentication unit 215 assigns a session ID for communication with the terminal 30. Further, the authentication unit 215 stores the user name as a login user name in the memory device 203 in association with the session ID, for example. The authentication unit 215 returns an authentication result (information indicating success or failure of authentication) to the front end unit 214 (S305).

  When the authentication result indicates that the authentication is successful, the front end unit 214 returns HTML data including screen information of the initial screen (hereinafter referred to as “initial screen data”) and the session ID to the terminal 30 (S306). Note that a session ID is specified in subsequent requests from the UI unit 31. A login user name or the like can be identified by the session ID.

  The UI unit 31 of the terminal 30 displays an initial screen on the terminal 30 based on the returned initial screen data. The display content of the initial screen is not limited to a predetermined one. In the present embodiment, the initial screen includes a menu item group for selecting a desired function from the functions provided by the failure support service.

  The developer in charge selects a menu item for instructing display of a list of failure information in order to confirm the failure information notified by the notification mail. The UI unit 31 transmits a failure information acquisition request to the failure support apparatus 20 based on information defined in the initial screen data for such an operation (S307).

  In response to receiving the failure information acquisition request, the front-end unit 214 acquires failure information corresponding to the login user name associated with the session ID specified in the acquisition request from the failure information storage unit 221 ( S308). The failure information corresponding to the login user name is, for example, failure information whose development person name stored for the failure information matches the login user name. Alternatively, for example, the development person name stored for the failure information may be failure information that matches the group name to which the login user name belongs. That is, the failure information corresponding to the Guin user name is failure information in which the identification name specified according to a predetermined rule based on the login user name matches the name of the person in charge of development. Note that the failure information acquired in step S308 may be limited to the information whose status is a predetermined value. For example, failure information whose status value is “corresponding” indicating that it has already been handled (resolved) may be excluded from acquisition targets.

  Subsequently, the front-end unit 214 generates HTML data (hereinafter referred to as “failure list screen data”) for displaying the acquired failure information list screen (hereinafter referred to as “failure list screen”) (S309). ). In the failure list screen data, for example, for each failure related to the acquired failure information, some information (for example, part or all of error information) included in the failure information, status values, and the like are displayed. Is generated as follows. Subsequently, the front end unit 214 returns the generated failure list screen data to the terminal 30 (S310).

  The UI unit 31 of the terminal 30 causes the terminal 30 to display a failure list screen based on the returned failure list screen data. The developer in charge can know details of the failure that has occurred by browsing the failure list screen.

  Note that the processing of FIG. 11, that is, step S301, does not necessarily have to be started in response to a link click in the notification mail. For example, the developer may start by inputting a URL for the failure support service to the UI unit 31. That is, the developer may be operated so as to access the failure support service as a daily work. Therefore, the developer in charge can recognize the occurrence of a new failure by accessing the failure response support service even if the notification mail is not transmitted.

  When the person in charge of development selects one fault on the fault list screen and inputs an instruction to construct the evaluation environment 250 regarding the fault, the UI unit 31 sets the evaluation environment 250 based on the definition contents of the fault list screen data. A construction request is transmitted to the failure handling support apparatus 20 (S311). In the request, the failure ID of the selected failure is specified.

  In response to receiving the evaluation environment 250 construction request, the front-end unit 214 designates the failure ID designated in the request and requests the evaluation environment construction unit 216 to construct the evaluation environment 250 (S312). Subsequently, the evaluation environment construction unit 216 acquires failure information associated with the failure ID from the failure information storage unit 221 (S313). Subsequently, the evaluation environment construction unit 216 generates an evaluation environment 250 (S314). Specifically, the hardware imitation unit 251 corresponding to the model (model of the multifunction peripheral 10a) indicated by the model information included in the device information of the acquired failure information (hereinafter referred to as “target failure information”) A virtual environment including the platform imitation unit 252 corresponding to the version information of the application platform 122 is generated as the evaluation environment 250. The generation destination of the evaluation environment 250 may be a computer (not shown) connected to the failure support apparatus 20 via a network, or may be a virtual machine that operates on the computer or the failure support apparatus 20. .

  The evaluation environment construction unit 216 further includes the entity of each application 123 included in the list of application IDs and version information of the application 123 installed in the multifunction machine 10a included in the device information of the target failure information ( Program module) is installed in the evaluation environment 250. The program module is acquired from the module storage unit 224. That is, the module storage unit 224 stores the program module of each application 123 in association with the application ID, version information, and the like.

  As described above, the evaluation environment 250 is generated so as to have a hardware configuration and a software configuration that simulates a hardware configuration and a software configuration of the MFP 10a in which a failure has occurred. In addition, in order to make the evaluation environment 250 closer to the hardware configuration and the software configuration of the MFP 10a in which the failure has occurred, processing other than the above may be executed.

  Subsequently, the evaluation environment construction unit 216 returns a response indicating completion of construction of the evaluation environment 250 to the front end unit 214 (S315). The front end unit 214 returns a response indicating completion of the construction of the evaluation environment 250 to the terminal 30 (S316). The front end unit 214 receives the status value stored in the failure information storage unit 221 for the target failure information in response to receiving a response indicating completion of the construction of the evaluation environment 250 from the evaluation environment building unit 216. For example, it may be updated to “Evaluation environment built”.

  Subsequently, the developer in charge selects a failure related to the target failure information on the failure list screen, and inputs an execution instruction for automatic evaluation (reproduction test execution instruction) regarding the failure. In response to the input of the execution instruction, the UI unit 31 transmits an automatic evaluation execution request to the failure handling support apparatus 20 based on the definition content of the failure list screen data (S317). In the request, the failure ID of the selected failure is specified.

  In response to receiving the automatic evaluation execution request, the front-end unit 214 specifies the failure ID specified in the request and requests the automatic evaluation unit 217 to execute automatic evaluation (S318). Subsequently, the automatic evaluation unit 217 acquires failure information associated with the failure ID from the failure information storage unit 221 (S319). Subsequently, the automatic evaluation unit 217 generates a test scenario (S320). The test scenario is a set of input information for the evaluation environment 250, for example. The test scenario is generated based on, for example, a history of operation event information included in the target failure information, a history of device event information, and the like. In other words, the test scenario includes information that can reproduce the operation performed by the user in the MFP 10a in which the failure has occurred. Subsequently, the automatic evaluation unit 217 performs automatic evaluation on the evaluation environment 250 based on the generated test scenario (S321). For example, as indicated by the test scenario, an operation instruction by the user is input to the evaluation environment 250 in a pseudo manner. In addition, the execution method of automatic evaluation may be the same as that of a well-known automatic evaluation system.

  Subsequently, the automatic evaluation unit 217 returns the execution result of the automatic evaluation to the front end unit 214 (S322). The return timing of the automatic evaluation execution result may vary depending on the execution result of the automatic evaluation. For example, when a failure is reproduced during execution of automatic evaluation, the execution result of automatic evaluation may be returned when the failure is reproduced. Further, when the failure is not reproduced during execution of automatic evaluation, the execution result of automatic evaluation may be returned when the test scenario is completed. Further, the content of the execution result of the automatic evaluation may be information indicating the content of the failure when the failure is reproduced, or information indicating the state of the evaluation environment 250 at the time when the failure occurs. If the failure has not been reproduced, the information may indicate that the failure is normal.

  Subsequently, the front-end unit 214 generates data (hereinafter referred to as “evaluation result screen data”) indicating a screen (hereinafter referred to as “evaluation result screen”) on which information indicating the execution result of the automatic evaluation is displayed (hereinafter referred to as “evaluation result screen data”). S323). The front end unit 214 returns the evaluation result screen data to the terminal 30 (S324).

  The UI unit 31 of the terminal 30 displays an evaluation result screen on the terminal 30 based on the evaluation result screen data. The developer in charge reviews the countermeasures with reference to the evaluation result screen.

  In the evaluation environment 250, other evaluations desired by the person in charge of development may be executed in addition to the execution of the automatic evaluation. For example, a program created for failure analysis may be executed in the evaluation environment 250.

  As described above, according to the present embodiment, the person in charge of development is automatically specified based on the trouble information transmitted from the device, and the occurrence of the trouble is notified to the person in charge of development. Therefore, the person in charge of development can quickly recognize the occurrence of a failure, and can start analyzing the failure. Therefore, it is possible to improve the efficiency of dealing with a failure related to the program in the device.

  Further, according to the present embodiment, an evaluation environment 250 (failure reproduction environment) as a virtual environment that imitates the hardware environment and software environment of the device is automatically generated based on the failure information transmitted from the device. Is done. Therefore, the person in charge of development can quickly analyze the cause of the failure using the evaluation environment 250.

  Furthermore, according to the present embodiment, the operation performed on the device is automatically reproduced in the evaluation environment 250 based on the failure information transmitted from the device. As a result, it is possible to increase the possibility that the occurrence of a failure is reproduced in the evaluation environment 250.

  In the present embodiment, the multifunction device 10a has been described as an example of the device. However, the present embodiment is applied to other image forming apparatuses such as the printer 10b and other devices such as the projector 10c. Also good. Further, the present embodiment may be applied to a device (not shown) such as a digital camera. Furthermore, the present embodiment may be applied to an information processing system such as the conference system 10d.

  By the way, the functions of the failure support apparatus 20 may constitute a part of the integrated development environment. FIG. 12 is a diagram illustrating an example of an integrated development environment. In FIG. 12, the same parts as those in FIG. In FIG. 12, the failure information receiving unit 211, the person-in-charge specifying unit 212, the failure notification unit 213, the failure information storage unit 221, and the application development information storage unit 222 are omitted for convenience.

  In FIG. 12, the integrated development environment 40 further includes a source code storage unit 231, a source code editing unit 232, a build unit 233, a test unit 234, a debug unit 235, a continuous integration unit 236, and the like.

  The source code storage unit 231 stores the source code of the application 123. The source code editing unit 232 edits the source code to be edited in response to an instruction input via the source code editing screen displayed on the terminal 30 by the UI unit 31. The build unit 233 executes build (compile, link, etc.) for the source code stored in the source code storage unit 231. The test unit 234 supports execution of a test related to the application 123 after the build. The debugging unit 235 provides debugging support for the application 123 after the build. For example, the continuous integration unit 236 automatically executes a build and a test on a source code that has not been built after being edited by the source code editing unit 232, and stores a program module of the application 123 after the build as a module. Upload to the unit 224.

  By making the function of the failure support apparatus 20 a part of the integrated development environment 40, a more convenient service can be provided to the developer. That is, the developer builds the evaluation environment 250, executes automatic evaluation in the evaluation environment 250, edits the source code of the application 123 that has received the execution result of automatic evaluation, and edits the source code after editing in the same virtual space. Build, post-build tests and debugging can be executed.

  The integrated development environment 40 shown in FIG. 12 may be realized by the same computer or computer group as the failure handling support apparatus 20, or a further computer or computer group is connected to the failure handling support apparatus 20. May be realized.

  As mentioned above, although the Example of this invention was explained in full detail, this invention is not limited to such specific embodiment, In the range of the summary of this invention described in the claim, various deformation | transformation・ Change is possible.

1 Failure Response Support System 10a Multifunction Device 10b Printer 10c Projector 10d Conference System 11 Controller 12 Scanner 13 Printer 10b
14 Modem 15 Operation Panel 16 Network Interface 17 SD Card Slot 20 Failure Response Support Device 30 Terminal 31 UI Unit 40 Integrated Development Environment 80 SD Card 111 CPU
112 RAM
113 ROM
114 HDD
115 NVRAM
121 device control unit 122 application platform 123 application 124 log storage unit 130 interface unit 131 device event reception unit 132 device information acquisition unit 133 operation event reception unit 134 application management unit 135 platform management unit 136 log management unit 137 fault information transmission unit 200 drive Device 201 Recording medium 202 Auxiliary storage device 203 Memory device 204 CPU
205 Interface device 211 Failure information receiving unit 212 Person in charge identification unit 213 Failure notification unit 214 Front end unit 215 Authentication unit 216 Evaluation environment construction unit 217 Automatic evaluation unit 221 Failure information storage unit 222 Application development information storage unit 223 Authentication information storage unit 224 Module storage unit 231 Source code storage unit 232 Source code editing unit 233 Build unit 234 Test unit 235 Debug unit 236 Continuous integration unit 250 Evaluation environment 250
B bus N1 network

JP-A-6-169366

Claims (10)

A receiving unit for receiving failure information transmitted from the device;
Referring to the storage unit that stores the identification information of the notification destination regarding the failure of the program in association with the identification information of the program, the notification destination of the program is specified based on the identification information of the program included in the failure information A specific part,
A notification unit that transmits information for notifying the occurrence of a failure indicated by the failure information to a terminal related to the notification destination;
Failure handling having a generation unit that generates a virtual environment that imitates the hardware environment and software environment of the device based on the model information of the device and the software configuration information of the device included in the failure information Support device. The are included in the failure information, based on the operation history for the equipment, the operation performed on the device, the failure handling assistance device according to claim 1, further comprising a reproducing unit to reproduce in the virtual environment. The failure response support apparatus according to claim 2 , wherein the reproduction unit generates a test scenario based on the operation history, and reproduces an operation performed on the device in the virtual environment based on the test scenario. . A failure response support system including a device and an information processing apparatus connected to the device via a network,
The information processing apparatus includes:
A receiving unit for receiving failure information transmitted from the device;
Referring to the storage unit that stores the identification information of the notification destination regarding the failure of the program in association with the identification information of the program, the notification destination of the program is specified based on the identification information of the program included in the failure information A specific part,
A notification unit that transmits information for notifying the occurrence of a failure indicated by the failure information to a terminal related to the notification destination;
Failure handling having a generation unit that generates a virtual environment that imitates the hardware environment and software environment of the device based on the model information of the device and the software configuration information of the device included in the failure information Support system. The information processing apparatus includes:
The failure handling support system according to claim 4 , further comprising: a reproduction unit that reproduces an operation performed on the device in the virtual environment based on an operation history for the device included in the failure information. The failure response support system according to claim 5 , wherein the reproduction unit generates a test scenario based on the operation history, and reproduces an operation performed on the device in the virtual environment based on the test scenario. . A reception procedure for receiving failure information transmitted from the device;
A specific procedure for identifying the notification destination of the program based on the identification information of the program included in the failure information with reference to a storage unit that stores the identification information of the notification destination of the program in association with the identification information of the program When,
A notification procedure for transmitting information for notifying the occurrence of a failure indicated by the failure information to a terminal related to the notification destination;
The computer executes a generation procedure for generating a virtual environment imitating the hardware environment and software environment of the device based on the model information of the device and the software configuration information of the device included in the failure information Support method for dealing with disabilities. The failure handling method according to claim 7 , wherein the computer executes a reproduction procedure for reproducing an operation performed on the device in the virtual environment based on an operation history for the device included in the failure information. Support method. 9. The failure handling support method according to claim 8 , wherein the reproduction procedure generates a test scenario based on the operation history and reproduces an operation performed on the device in the virtual environment based on the test scenario. . A reception procedure for receiving failure information transmitted from the device;
A specific procedure for identifying the notification destination of the program based on the identification information of the program included in the failure information with reference to a storage unit that stores the identification information of the notification destination of the program in association with the identification information of the program When,
A notification procedure for transmitting information for notifying the occurrence of a failure indicated by the failure information to a terminal related to the notification destination;
The computer executes a generation procedure for generating a virtual environment that imitates the hardware environment and software environment of the device based on the device model information and the software configuration information of the device included in the failure information. Disability response support program.

Images