JP2014056547A - Counter-failure support device, counter-failure support system, counter-failure support method, and counter-failure support program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a counter-failure support device which can efficiently cope with program failure in an apparatus.SOLUTION: A counter-failure support device comprises: a reception unit which receives failure information transmitted from an apparatus; a generation unit which, on the basis of apparatus type information of the apparatus and configuration information of software of the apparatus included in the failure information, generates a first virtual environment imitating hardware environment and software environment of the apparatus, and a second virtual environment having the software of which version is partially different; and a reproduction unit which reproduces operations performed on the apparatus in the first virtual environment and the second virtual environment on the basis of an operation history which is included in the failure information and indicates operations performed on the apparatus.

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.

  Conventionally, 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, Patent Document 1). For example, the user can improve the efficiency of the business by installing an application program suitable for his / her business in the device.

  Depending on the function expansion and the like, the application platform has a plurality of versions. Each application program is required to be guaranteed to operate on a plurality of versions of the application platform. In addition, the application program itself has a plurality of versions due to bug correction and function enhancement.

  As a result, in the market, a plurality of environments are constructed with respect to a combination of the application platform version and the application program version. A manufacturer of a device, a software vendor, or the like is required to promptly respond to a failure in any one of a plurality of assumed environments.

  However, the greater the number of application platform or application program versions, the greater the number of version combinations. In order to cope with failures in a plurality of user environments in parallel, for each user environment, a device, an application platform, and an application that can reproduce a state close to the user environment are prepared. There is a need. Such work was a very heavy burden on the developer side.

  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.

  In order to solve the above problem, the failure support apparatus includes a receiving unit that receives failure information transmitted from a device, model information of the device and configuration information of software of the device included in the failure information, A generation unit that generates a first virtual environment that imitates a hardware environment and a software environment of the device, and a second virtual environment that has a different version of the software, and is included in the failure information And a reproduction unit that reproduces an operation performed on the device in the first virtual environment and the second virtual environment based on an operation history of the device.

  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. FIG. 3 is a diagram illustrating a software configuration example of a multifunction machine 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 sequence diagram for demonstrating an example of the process sequence of the upload process of a correction version application. It is a figure which shows an example of 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 response support apparatus 20 is a service (hereinafter referred to as a “failure response support service”) for supporting the failure response by the developer regarding the response to the failure that has occurred in the device in the user environment E1, especially the 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 a person who is 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 sold so far and within 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. At the time when the 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 login 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. In this case, the developer in charge can recognize the occurrence of a new failure by accessing the failure response support service without sending a notification mail.

  When the person in charge of development selects one fault on the fault list screen and inputs an execution instruction for automatic evaluation (execution instruction for a reproduction test), the UI unit 31 stores the fault list screen data according to the input of the execution instruction. Based on the definition, an automatic evaluation execution 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 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 (S312).

Subsequently, the automatic evaluation unit 217 specifies the failure ID specified in the automatic evaluation execution request, and requests the evaluation environment construction unit 216 to construct the evaluation environment 250 (S313).
Subsequently, the evaluation environment construction unit 216 acquires failure information associated with the failure ID from the failure information storage unit 221 (S314). Subsequently, the evaluation environment construction unit 216 generates an evaluation environment 250 (S315). 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 automatic evaluation unit 217 (S316). Note that the evaluation environment construction unit 216 may update the status value stored in the failure information storage unit 221 with respect to the target failure information, for example, “evaluation environment built”.

  Subsequently, the automatic evaluation unit 217 acquires failure information associated with the failure ID specified in the automatic evaluation execution request from the failure information storage unit 221 (S317). Subsequently, the automatic evaluation unit 217 generates a test scenario (S318). 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 (S319). 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. The automatic evaluation unit 217 stores the execution result of the automatic evaluation in, for example, the memory device 203 or the auxiliary storage device 202.

  Steps S313 to S319 include the version of the application platform 122 and the application ID included in the error information of the failure information related to the failure ID specified in the automatic evaluation execution request (hereinafter referred to as “failure target application ID”). The combination of the versions of the application 123 identified by is changed and executed repeatedly. That is, the automatic evaluation is executed for a state or environment different from the state or environment where the failure has occurred.

  Specifically, following step S319, the automatic evaluation unit 217 requests the evaluation environment construction unit 216 to construct the evaluation environment 250 again (S313). At this time, the version of the application platform 122 is designated. Also, the failure target application ID and the version of the application 123 related to the failure target application ID are specified. The combination of the version of the application platform 122 and the version of the application platform 122 is specified to be different from the combination that has already been automatically evaluated. That is, at least one of the version of the application platform 122 and the version of the application platform 122 is designated with a value different from the version related to the combination in the already executed automatic evaluation.

  In step S315, the evaluation environment construction unit 216 generates the evaluation environment 250 including the platform imitation unit 252 corresponding to the specified version of the application platform 122. Further, the evaluation environment construction unit 216 installs the designated version in the evaluation environment 250 for the application 123 related to the failure target application ID.

  Therefore, in the subsequent step S319, the version of the application platform 122 and the version of the application 123 related to the failure target application ID and the failure target application ID are automatically evaluated for combinations different from the combinations that have already been automatically evaluated. Is done.

  Usually, for each version of each application 123, the version of the application platform 122 guaranteed as the operating environment of the version is often clarified. Therefore, for example, each version of each application 123 may be stored in the auxiliary storage device 202 in association with the version of the application platform 122 guaranteed as the operating environment of the version. The automatic evaluation unit 217 specifies the version of the application platform 122 associated with the version for each version of the application 123 related to the failure target application ID, and builds the evaluation environment 250. 216 may be requested.

  When steps S313 to S319 are executed for all combinations of the version of the application 123 related to the failure target application ID and the version of the application platform 122 (for example, all combinations associated with the auxiliary storage device 202), The automatic evaluation unit 217 returns the execution result of the automatic evaluation to the front end unit 214 (S320). The automatic evaluation execution result returned here is an automatic evaluation stored in the memory device 202 or the auxiliary storage device 202 for each combination of the version of the application 123 related to the failure target application ID and the version of the application platform 122. Is a set of execution results. The content of the execution result of the automatic evaluation for one combination may be information indicating the content of the failure when the failure is reproduced, or information indicating the state of the evaluation environment 250 when the failure occurs. . If the failure has not been reproduced, the information may indicate that the failure is normal.

  In the above example, the combination of the version of the application 123 and the version of the application platform 122 is changed and automatic evaluation is repeated. However, the model of the multifunction machine 10a is also added to the components of the combination. May be. In this case, in step S315 repeatedly executed, the hardware imitation unit 251 corresponds to the model related to the combination that is the execution target.

  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”). S321). The front end unit 214 returns evaluation result screen data to the terminal 30 (S322).

  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. Here, regarding the combination of the version of the application 123 related to the failure target application ID and the version of the application platform 122 associated with each version, the evaluation result screen includes not only the combination in the environment where the failure has occurred, The execution results of automatic evaluation are also included for other combinations. Therefore, the person in charge of development can confirm in which combination the failure is reproduced and in which combination the failure is not reproduced. As a result, the person in charge of development can improve the work for handling the failure. For example, the person in charge of development can narrow down a portion that is different between a combination in which a failure is reproduced and a combination in which the failure is not reproduced as an investigation range. For example, assume that the first combination and the second combination have the same version of the application platform 123 and different versions of the application program 122. When the failure is reproduced in the first combination and the failure is not reproduced in the second combination, the difference between the application program 122 related to the first combination and the application program 122 in the second combination is quickly investigated. The cause of the failure can be identified.

  Thereafter, the developer in charge performs, for example, correction of the source code of the application 123 related to the failure target application ID, compilation of the corrected source code, and the like. As a result, when a modified version of the program module of the application 123 is created, for example, the processing shown in FIG. 12 is executed.

  FIG. 12 is a sequence diagram for explaining an example of a processing procedure of upload processing of a modified version application.

  The developer in charge of the predetermined screen displayed on the terminal 30 has the file name of the program module of the corrected application 123, the application ID of the application 123, and the failure ID of the failure that caused the correction. When the upload instruction is input, the UI unit 31 specifies the file related to the input file name (that is, the program module of the application 123), the input application ID and the failure ID, An upload request is transmitted to the failure support apparatus 20 (S401).

  Upon reception of the upload request, the front-end unit 214 specifies the program module of the application 123 specified in the request, the application ID, and the failure ID, and requests the automatic evaluation unit 217 to execute automatic evaluation. (S402). Steps S403 to S409 may be the same as steps S313 to S319 in FIG. However, for the application 123 related to the application ID specified in the upload request, the program module of the modified version of the application 123 specified in the upload request is installed in the evaluation environment 250. Steps S403 to S409 may not be repeated for each combination of each version of the application 123 and each version of the application platform 123. This is because the automatic evaluation executed in FIG. 12 is an automatic evaluation for confirming that the cause of the failure has been removed.

  If the failure is not reproduced as a result of the automatic evaluation, the automatic evaluation unit 217 associates the corrected version of the application 123 with the application ID specified in the upload request and the latest version information related to the application ID. Then, it is registered in the module storage unit 224 (S410). The application 123 registered in the module storage unit 224 can be downloaded from a predetermined website. Accordingly, in the user environment E1, the modified version of the application 123 can be downloaded and installed in the multifunction machine 10a.

  Subsequently, the automatic evaluation unit 217 returns a response indicating that the upload has been successful to the front end unit 214 (S411). The front end unit 214 returns the response to the terminal 30 (S412).

  As described above, according to the present embodiment, the evaluation environment 250 (failure reproduction environment) as a virtual environment that mimics the hardware environment and software environment of the device is automatically set based on the failure information transmitted from the device. Generated automatically. Therefore, the person in charge of development can quickly analyze the cause of the failure using the evaluation environment 250.

  The evaluation environment 250 is generated for each combination of the model of the multifunction machine 10a, the version of the application platform 122, the version of the application 123, and the like, and automatic evaluation is performed for each evaluation environment 250 related to each combination. Therefore, even when a plurality of models are provided in the market and a plurality of versions of the application platform 122, the application 123, and the like are provided, the failure handling can be made efficient.

  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.

  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.

  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. 13 is a diagram illustrating an example of an integrated development environment. In FIG. 13, the same parts as those in FIG. In FIG. 13, 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. 13, 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 the 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. 13 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.

  In the present embodiment, the failure information receiving unit 211 is an example of a receiving unit. The evaluation environment construction unit 216 is an example of a generation unit. The automatic evaluation unit 217 is an example of a reproduction unit. The person-in-charge specifying unit 212 is an example of a specifying unit. The failure notification unit 213 is an example of a notification unit.

  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 2005-269619 A

Claims (6)

A receiving unit for receiving failure information transmitted from the device;
A first virtual environment that imitates the hardware environment and software environment of the device based on the model information of the device and the software software configuration information included in the failure information, and a part of the software A generation unit that generates a second virtual environment with different versions of
A reproduction unit that reproduces an operation performed on the device in the first virtual environment and the second virtual environment based on an operation history of the device included in the failure information; Fault response support device.   The failure handling support apparatus according to claim 1, 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. . The failure information notification destination is specified based on the program identification information included in the failure information with reference to a storage unit that stores the identification information of the notification destination regarding the failure of the program in association with the program identification information. Specific part to do,
The failure handling support apparatus according to claim 1, further comprising: a notification unit that transmits information for notifying occurrence of a failure indicated by the failure information to a terminal related to the notification destination. A failure 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;
A first virtual environment that imitates the hardware environment and software environment of the device based on the model information of the device and the software software configuration information included in the failure information, and a part of the software A generation unit that generates a second virtual environment with different versions of
A reproduction unit that reproduces an operation performed on the device in the first virtual environment and the second virtual environment based on an operation history of the device included in the failure information; Fault response support system. A reception procedure for receiving failure information transmitted from the device;
A first virtual environment that imitates the hardware environment and software environment of the device based on the model information of the device and the software software configuration information included in the failure information, and a part of the software A generation procedure for generating a second virtual environment with different versions of
A reproduction procedure for reproducing an operation performed on the device in the first virtual environment and the second virtual environment based on an operation history with respect to the device included in the failure information. The failure response support method executed by A reception procedure for receiving failure information transmitted from the device;
A first virtual environment that imitates the hardware environment and software environment of the device based on the model information of the device and the software software configuration information included in the failure information, and a part of the software A generation procedure for generating a second virtual environment with different versions of
A reproduction procedure for reproducing an operation performed on the device in the first virtual environment and the second virtual environment based on an operation history with respect to the device included in the failure information. Failure response support program to be executed.

Images