JP2009020863A - Image forming apparatus, information processor, fault analysis support method, and fault analysis support program - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide an image forming apparatus, an information processor, a fault analysis support method, and a fault analysis support program, for appropriately supporting the analysis of the cause of a fault due to a program. <P>SOLUTION: The image forming apparatus capable of executing the program includes: a script data acquiring means for acquiring script data corresponding to the contents of a fault in response to program fault detection: a starting means for starting the program after acquisition of the script data; an operating means for generating an input with respect to the program, based on the script data; and a log recording means for recording the contents of a usage request or consumption in a storage device as log information in response to at least the usage request of a prescribed function in the image forming apparatus by the program or the consumption of the prescribed resource. <P>COPYRIGHT: (C)2009,JPO&INPIT

Description

  The present invention relates to an image forming apparatus, an information processing apparatus, a failure analysis support method, and a failure analysis support program, and more particularly to an image formation apparatus, an information processing apparatus, a failure analysis support method, and a failure analysis support program to which a program can be added.

  In recent years, there are some image forming apparatuses that are mainly called multifunction peripherals or multi-functional peripherals, and that are capable of developing and installing new applications using published API (Application Program Interface) after shipment. (For example, patent document 1). In such an image forming apparatus, not only an application developed by a vendor of the image forming apparatus but also an application developed by another software vendor may be installed and used.

By the way, in the case of an embedded device such as an image forming apparatus, restrictions on resources such as a memory are severer than those of a general-purpose computer. Accordingly, there are restrictions on the amount of resources used, such as application consumption memory, and each software vendor designs an application that operates within the scope of the restrictions (hereinafter referred to as “resource restrictions”). Is required.
JP 2005-269619 A

  However, as a software vendor, there is a desire to provide more convenient and highly functional applications. In general, the higher the function is, the more memory consumption by a program tends to increase. Therefore, there is a possibility that the application is provided to the market in a state where the resource limitation is not observed due to the convenience of the end user.

  In addition, even if each application is created in compliance with resource restrictions, the resources of the image forming apparatus are depleted depending on the user's usage mode, such as when multiple applications are used in parallel. There is a possibility that.

  When resources are depleted, the operation of the application is not guaranteed and not only is disadvantageous for the end user, but also the image forming device vendor and the application development vendor have a burden of investigating the cause. There is a problem that occurs.

  The present invention has been made in view of the above points, and provides an image forming apparatus, an information processing apparatus, a failure analysis support method, and a failure analysis support program capable of appropriately supporting failure cause analysis by a program. For the purpose of provision.

  Accordingly, in order to solve the above-described problem, the present invention provides an image forming apparatus capable of executing a program, and script data acquisition means for acquiring script data corresponding to the content of the failure in response to detection of occurrence of the failure of the program An activation unit that activates the program after obtaining the script data, an operation unit that generates an input to the program based on the script data, a request for using a predetermined function of the image forming apparatus by the program, and a predetermined Log recording means for recording the content of the use request or the content of the consumption as log information in a storage device in response to the occurrence of at least one of the consumption of the resource.

  In such an image forming apparatus, it is possible to appropriately perform a cause analysis of a failure by a program.

  According to the present invention, it is possible to provide an image forming apparatus, an information processing apparatus, a failure analysis support method, and a failure analysis support program that can appropriately perform failure cause analysis by a program.

  FIG. 1 is a diagram for explaining an outline of an embodiment of the present invention. In the embodiment of the present invention, the multifunction machine 10 is an example of an image forming apparatus to which an application can be added. In the figure, two multifunction devices 10 are shown on the upper and lower sides, but this shows the same multifunction device 10 over time.

  In the present embodiment, the application newly installed in the multifunction machine 10 is first provisionally activated (S11). Temporary activation refers to an application for investigating resource consumption by an application and services (functions) in the multifunction peripheral 10 used by the application (information indicating these is hereinafter referred to as “application operation information”). It means starting up. In the present embodiment, the temporarily activated application cannot provide the original function of the application to the user. During the temporary activation, the multifunction machine 10 outputs the application operation information as a temporary activation log (S12). When the temporary activation is completed, the multifunction machine 10 determines whether the temporary activation is successful based on the temporary activation log (S13). Successful provisional activation means that the operation of the provisionally activated application is within a predetermined limit (resource consumption, restrictions on services in the MFP 10 to be used, etc.). That means. The failure of provisional activation means that it has been confirmed that the operation of the provisionally activated application does not comply with a predetermined restriction.

  If the provisional activation is successful, the application is installed in the multifunction machine 10 and is ready for actual activation. Therefore, when there is an activation instruction from the user, the actual activation is performed (S14). The term “actual activation” is a term for provisional activation and refers to activation of an application in order to exhibit the original function of the application. That is, the normal use state of the application is realized by this activation. At the time of actual activation, the multifunction machine 10 controls the operation of the application based on the temporary activation log. For example, the activation of the application is rejected, the timing of starting the application is limited, the state transition of the application (progress of processing) is limited, and the use of the service of the MFP 10 by the application is limited.

  As described above, the multifunction machine 10 performs provisional activation for a newly added (installed) application in advance, and controls the operation at the actual activation based on the provisional activation log acquired at the time of provisional activation. be able to. Therefore, when the operation of an application that does not comply with the predetermined restrictions on resource consumption, etc. is restricted, or when multiple applications are started simultaneously (in parallel), the timing of resource consumption of each application Can be controlled.

  This will be specifically described below. FIG. 2 is a diagram illustrating a hardware configuration example of the multifunction peripheral according to the embodiment of the present invention. In FIG. 2, the multifunction machine 10 includes a controller 201, an operation panel 202, a facsimile control unit (FCU) 203, an imaging unit 121, a printing unit 122, and the like.

  The controller 201 includes a CPU 211, ASIC 212, NB221, SB222, MEM-P231, MEM-C232, HDD (hard disk drive) 233, memory card slot 234, NIC (network interface controller) 241, USB device 242, IEEE 1394 device 243, and Centronics device. 244.

  The CPU 211 is an IC for various information processing. The ASIC 212 is an IC for various image processing. The NB 221 is a north bridge of the controller 201. The SB 222 is a south bridge of the controller 201. The MEM-P 231 is a system memory of the multifunction machine 10. The MEM-C 232 is a local memory of the multifunction machine 10. The HDD 233 is a storage of the multifunction machine 10. The memory card slot 234 is a slot for setting the memory card 235. The NIC 241 is a controller for network communication using a MAC address. The USB device 242 is a device for providing a USB standard connection terminal. The IEEE 1394 device 243 is a device for providing a connection terminal of the IEEE 1394 standard. The Centronics device 244 is a device for providing a Centronics specification connection terminal.

  The operation panel 202 is hardware (operation unit) for an operator to input to the multifunction device 10 and hardware (display unit) for an operator to obtain an output from the multifunction device 10.

  FIG. 3 is a diagram illustrating a software configuration example of the multifunction machine according to the embodiment of the present invention. In FIG. 3, the software of the multifunction machine 10 includes a JSDK application 30, a JSDK platform 40, a request path control unit 50, a native service layer 60, and the like. Each of these software functions when the CPU 211 processes a program recorded in the memory card 235 or other storage device.

  The native service layer 60 provides an upper module with an interface for using functions based on the hardware and software of the multifunction machine 10, and implements the function in response to the interface call (function use request). To control. For example, the native service layer 60 includes a module that provides an interface related to network communication control, a module that provides an interface related to facsimile control, and control of distribution processing of stored documents (document (image) data stored in the HDD 233). A module that provides an interface related to the image, and a module that provides an interface related to the control of the imaging unit 121 and the printing unit 122. A module that provides an interface related to control of the memory, HDD 233, etc., a module that provides an interface related to control of the operation panel 202, a module that provides an interface related to control of authentication processing and billing processing, a module that provides an interface related to user information management, etc. Is included.

  The JSDK platform 40 is a software platform that provides an execution environment for the JSDK application 30, and provides a Java (registered trademark) interface for the native service layer 60 to an upper module. The JSDK platform 40 includes a Java (registered trademark) standard class, a class library related to a class extended for the multifunction peripheral 10, a Java (registered trademark) virtual machine, and the like. For example, in the figure, a security manager 41 and a logging service 42 are shown as part of the JSDK platform 40.

  The security manager 41 restricts access to resources such as files, network sockets, and printers by the JSDK application 30 based on access control information defined in advance in the policy file. That is, the JSDK platform 40 is configured such that a call to the security manager 41 occurs when access to a resource occurs. The security manager 41 determines whether or not the resource can be accessed in response to the call. The security manager 41 may be realized using the SecurityManager class in the Java (registered trademark) standard.

  The logging service 42 outputs a provisional activation log 80 when the JSDK application 30 is provisionally activated.

  The JSDK platform 40 is implemented as an OSGi (Open Service Gateway initiative) platform. The OSGi (Open Service Gateway initiative) platform is a standardized technology by the OSGi Alliance, and a software platform that provides an execution environment for software components created based on open software componentization technology based on the Java (registered trademark) language. It is. On the OSGi platform, Java (registered trademark) language software is implemented in the form of software components called “bundles”. One bundle is composed of one JAR (Java ARchive) file, and can be installed independently and dynamically (without restarting the apparatus).

  The JSDK application 30 is an application (hereinafter referred to as “SDK application”) created using a dedicated SDK (software development kit) published on the JSDK platform 40. Among SDK applications, an application developed using Java (registered trademark) in particular as a language is referred to as a JSDK application, and is a target for temporary activation in the present embodiment.

  In the figure, as an example of the JSDK application 30, there are a SAS (SDK Application Service) manager 31, an application bundle 32, a service bundle 33, and the like. The SAS manager 31 performs control such as installation (addition), uninstallation (deletion), activation, and cancellation of activation of other JSDK applications 30 (such as the application bundle 32 and the service bundle 33).

  The application bundle 32 is a bundle as the JSDK application 30 that displays an operation screen on the operation panel 202 and is directly used (operated) by an end user via the operation screen. In the drawing, a scan application 321 is shown as an example of the application bundle 32. The scan application 321 is an application that realizes reading of an image from a document by the imaging unit 121.

  The service bundle 33 is a bundle as the JSDK application 30 for providing a service to the application bundle 32 and the like. That is, the service bundle 33 executes processing corresponding to each service bundle 33 in response to a call from the application bundle 32 or the like, and returns the processing result to the application bundle 32 or the like. In the figure, as an example of the service bundle 33, a scan service 331, a panel service 332, a temporary activation service 333, and the like are illustrated.

  The scan service 331 provides a service related to an image reading function. The panel service 332 provides a service related to display control of the operation panel 202. The provisional activation service 333 provides a service related to provisional activation processing control based on the description content of the provisional activation script 70. Details of the provisional activation script 70 will be described later.

  In the present embodiment, applications such as the application bundle 32 and the service bundle 33 operate according to a state transition model in which the state transitions in the order of init state → pause state → active state → destroy state (processing proceeds). . The init state is an initial state, and initial processing and the like are performed. The application immediately after the activation first transitions to the init state. The pause state is a standby state. The paused application waits until it can be executed. The active state is a state in which the original function of the application is executed. The destroy state is an end state. The application to be terminated transitions to the destroy state, and is terminated after performing termination processing (such as resource release).

  In order to realize such a state transition model, the application bundle 32 and the service bundle 33 are configured as follows. FIG. 4 is a diagram illustrating an implementation example of a state transition model of an application bundle or a service bundle. As shown in FIG. 4, the application bundle 32 and the service bundle 33 (referred to as “application bundle 32 etc.” in the description of FIG. 4) are configured by objects instantiated for each state. That is, the init state object 341, the pause state object 342, the active state object 343, and the destroy state object 344 are instantiated in association with the init state, pause state, active state, and destroy state.

  Upon receiving an event (message) that causes a state transition, the application bundle 32 and the like move processing control (control of the application) from the transition source object to the transition destination object. For example, control of processing moves from the init state object 341 to the pause state object 342. State transition is realized by this movement of control.

  Note that the operation of the application bundle 32 or the like according to the state transition model does not mean that the application must be implemented according to a certain state transition model in order to apply the present invention.

  The request path control unit 50 monitors a request (a request for using a predetermined function) from the JSDK application 30 to the native service layer 60, and determines whether the JSDK application 30 that issued the request is temporarily running. Thus, the notification path of the request is controlled. That is, a request from the JSDK application 30 that is provisionally activated is notified to the provisional activation service 333, and a request from the JSDK application 30 that is not provisionally activated (currently activated) is notified to the native service layer 60. .

  FIG. 5 is a diagram for explaining the main functions of the request path control unit. 5, the same parts as those in FIG. 3 are denoted by the same reference numerals. In FIG. 5, an application A 322 is the application bundle 32 that is fully activated. The application B 323 is an application bundle 32 that is provisionally activated. As shown in the drawing, the request path control unit 50 passes the call to the native service layer 60 performed through the JSDK platform 40 for the application A322 that has been fully activated (S21). Therefore, in this case, the MFP 10 actually operates under the control of the native service layer 60.

  On the other hand, for the application B 323 that is provisionally activated, the request path control unit 50 does not notify the native service layer 60 of a call to the native service layer 60 that is performed via the JSDK platform 40, and does not notify the provisional activation service 333. (S22). In this case, the provisional activation service 333 behaves like the native service layer 60 in a pseudo manner, and returns the result to the application B 323 in the same format as the native service layer 60. Therefore, from the application B 323, it seems that the native service layer 60 is normally called and the function is executed. As described above, at the time of provisional activation, the request path control unit 50 verifies the JSDK application 30 without causing the native service layer 60 or lower to function (that is, without actually operating the multifunction machine 10).

  Next, details of the temporary startup script 70 and the temporary startup service 333 will be described. FIG. 6 is a diagram for explaining the provisional activation script and the provisional activation service.

  As shown in FIG. 6, the temporary activation script 70 includes three script files: a main script 71, a scenario script 72, and a behavior script 73. The main script 71 defines information for specifying the scenario script 72 and the behavior script 73 used for provisional activation, criteria for determining whether or not provisional activation is successful, and the like. In the scenario script 72, a provisional activation scenario is defined. A scenario refers to an operation procedure via the operation panel 202 for an application that is provisionally activated. The behavior script 73 defines a behavior (emulation contents) for a call to the native service layer 60 notified to the temporary activation service 333 by the request path control unit 50.

  The main script 71 is interpreted by the temporary activation service 333. Accordingly, the provisional activation service 333 controls provisional activation according to the main script 71. The provisional activation service 333 generates a thread for interpreting the scenario script 72 (scenario service 334) and a thread for interpreting the behavior script 73 (behavior service 335).

  The scenario service 334 functions as a pseudo operator who inputs an operation instruction for the temporarily activated application according to the scenario script 72. A call to the native service layer 60 based on the application generated in response to an operation instruction of the scenario service 334 is notified to the behavior service 335 by the request path control unit 50. The behavior service 335 performs emulation for the notified call in accordance with the definition of the behavior script 73 and, as a result, makes a response in the same format as the native service layer 60. A response in the same format as that of the native service layer 60 is performed, so that it appears to the application that the native service layer 60 has been called.

  Hereinafter, a processing procedure of the multifunction machine 10 will be described. FIG. 7 is a sequence diagram for explaining a processing procedure related to provisional activation of the multifunction machine according to the first embodiment.

  When the installation of the application is instructed, the SAS manager 31 searches the application management file recorded on the SD card inserted in the memory card slot 234 of the multifunction peripheral 10 main body, and finds all the searched application management files. Is taken out from the SD card (S101). Here, the application management file is a file in which component elements of the application, information necessary for installation, and other management information (hereinafter referred to as “application information”) are recorded. The application management file is attached for each application. Therefore, when a plurality of JSDK applications 30 are recorded in the SD card, a plurality of application management files are extracted.

  For example, FIG. 8 is a diagram illustrating an example of application information recorded in the application management file of the scan application. The application information 410 shown in FIG. 8 is expressed in a format that is an extension of JNLP (Java Network Launching Protocol (JSR-56 specification)) based on the XML (eXtensible Markup Language) format.

  The application information 410 is mainly composed of an information element 411 surrounded by <information> tags, a resource element 412 surrounded by <rsource> tags, a pseudo-boot element 413 surrounded by <pseudo-boot> tags, and <xlet It is composed of xlet elements 414 surrounded by -desc> tags.

  Information for identifying an application (scan application 321) is mainly recorded in the information element 411. For example, the product-id element 4111 has the product ID of the scan application 321, the title element 4112 has the title (application name) of the scan application 321, and the vendor element 4113 has the development vendor name (description 4113) of the scan application 321. It is recorded.

  In the resource element 412, information related to resources necessary for executing the scan application 321 is recorded. For example, the file name (path name) of the JAR file of the scan application 321 is recorded as the value of the href attribute of the jar element 4121.

  In the pseudo-boot element 413, information related to provisional activation is defined. For example, the value of the trigger attribute 4131 of the pseudo-boot element 413 specifies the timing for executing temporary activation. In the example in the figure, “install” is set. This indicates that provisional activation is executed when the scan application 321 is installed. In addition, the value of the platform attribute 4132 specifies a platform on which temporary activation is performed. In the example in the figure, it is “same”. This indicates that provisional activation is executed on the same platform as the actual activation. In addition, as the value of the href attribute of the pb element 4133, the file name (“ScanApp.pb”) of the main script 71 of the provisional activation script 70 of the scan application 321 is designated. The pseudo-boot element 413 is recorded when temporary activation is required. Accordingly, whether or not provisional activation is necessary can be determined according to the presence or absence of the pseudo-boot element 413.

  The value of the visible attribute 4141 of the xlet element 414 records whether or not the scan application 321 performs screen display on the operation panel 202. In the example in the figure, “visible” is set. This means that the scan application 321 performs screen display.

  FIG. 8 shows an example of application information of the scan application 321, but application information is also defined in the same format for other applications.

  Subsequently, the SAS manager 31 determines applications that can be installed in the multifunction peripheral 10 based on the acquired application management file, and displays a list of applications that can be installed (for example, a list of application names) on the operation panel 202. (S102, S103).

  The operator selects an application to be installed from the list of applications displayed on the operation panel 202. Here, it is assumed that the scan application 321 is selected. When the scan application 321 is selected, a request to start installing the scan application 321 is notified to the SAS manager 31 (S104).

  In response to the installation start request, the SAS manager 31 requests the JSDK platform 40 to install the scan application 321 according to the contents (application information 410) of the application management file of the scan application 321 (S105). The JSDK platform 40 installs the scan application 321 as a bundle (S106).

  Subsequently, the SAS manager 31 checks whether or not a provisional activation instruction (pseudo-boot element 413) is recorded in the application information 410. If the instruction is recorded, the provisional activation of the scan application 321 is performed. Is started (S107). If the provisional activation service 333 has not been activated, the SAS manager 31 starts activation of the provisional activation service 333 (S108). First, when the SAS manager 31 requests the JSDK platform 40 to install the temporary activation service 333 (S109), the JSDK platform 40 installs the temporary activation service 333 (S110). Subsequently, when the SAS manager 31 requests the JSDK platform 40 to start the temporary startup service 333 (S111), the JSDK platform 40 starts the temporary startup service 333 (S112).

  When activated, the provisional activation service 333 registers interface information of services that can be provided by itself (the provisional activation service 333) in the JSDK platform 40 (S113). Subsequently, the provisional activation service 333 acquires the interface information of the request path control unit 50 from the JSDK platform 333 (S114). Here, the interface information refers to information required to call the request route control unit 50. The request path control unit 50 is activated when the multifunction machine 10 is activated, and the interface information is registered in the JSDK platform 40 at that time.

  Subsequently, the SAS manager 31 acquires the interface information of the temporary activation service 333 from the JSDK platform 40 (S115). Subsequently, the SAS manager 31 refers to the pb element 4133 of the application information 410 and acquires the main script 71 whose file name (“ScanApp.pb”) is specified in the pb element 4133. The SAS manager 31 requests the temporary activation service 333 to control temporary activation of the scan application 321 by transferring the main script 71 and the application name of the scan application 321 to the temporary activation service 333 (S116).

  FIG. 9 is a diagram illustrating a definition example of the main script in the first embodiment. The contents of each description of the main script 71 described in FIG. 9 will be described in the step in which the description is executed. In the present embodiment, the main script 71, the scenario script 72, and the behavior script 73 are recorded in the same SD card as the target application.

  The provisional activation service 333 notifies the request path control unit 50 of the application name of the scan application 321 that is the target of provisional activation, and a call request (message) from the scan application 321 to the native service layer 60 is sent to the provisional activation service 333. The request path control unit 50 is requested to notify (S117). The request path control unit 50 holds the application name notified here, and identifies the application that is the target of temporary activation.

  Subsequently, the provisional activation service 333 executes the description 711 of the main script 71. The description 711 defines that provisional activation is executed using a scenario script 72 whose file name is “ScanApp.s” and a behavior script 73 whose file name is “ScanApp.b”. Therefore, the provisional activation service 333 activates (generates) the scenario service 334 and transfers the scenario script 72 (ScanApp.s) to the scenario service 334 (S118). Further, the temporary activation service 333 activates (generates) the behavior service 335 and transfers the behavior script 73 (ScanApp.b) to the behavior service 335 (S119).

  FIG. 10 is a diagram illustrating a definition example of a scenario script in the first embodiment. In the scenario script 72 described in FIG. 10, after the operation screen of the scan application 321 is displayed, when the start button is pressed after 3 seconds have elapsed and the display of “Complete” is confirmed on the operation screen, the scenario script 72 It is defined that it is judged that it has worked. Such a definition is based on the premise that the operation screen of the scan application 321 is as follows.

  FIG. 11 is a diagram illustrating an example of the operation screen of the scan application. In FIG. 11, two operation screens are displayed. The left operation screen 510a shows an initial state (a state immediately after the operation screen is displayed). The operation screen 510b on the right side shows a state when the scan application 321 ends normally. In the following, when both are not distinguished, they are referred to as “operation screen 510”.

  In the present embodiment, the operation screen 510 includes a label 511 indicating that the target is the scan application 321, a start button 512, and a Result label 513. The start button 512 is a button for allowing the user to input an instruction to start execution of the scan application 321. The Result label 513 is a label for displaying the processing result of the scan application 321. When the processing ends normally (when the scan is successful), a character string “Complete” is displayed as shown on the operation screen 510b. When the process ends abnormally (when scanning fails), for example, a character string “Error” is displayed. As shown in the operation screen 510a, nothing is displayed on the Result label 513 in the initial state.

  FIG. 12 is a diagram illustrating a definition example of a behavior script according to the first embodiment. Each description in the behavior script 73 has a meaning as setting information for the behavior service 335, not a definition executed for each step. That is, in the description 731, it is set to behave (emulate) like a normal operation with respect to a request regarding a scan service (a module that provides a service related to a scanner (imaging unit 121) in the native service layer 60). Yes. The description 732 is set to behave (emulate) as if the request related to a panel service (a module that provides a service related to the operation panel 202 in the native service layer 60) is normal.

  Subsequently, the SAS manager 31 requests the JSDK platform 40 to start the scan application 321 (S120). However, the scan application 321 is provisionally activated by the provisional activation service 333. In response to the activation request of the scan application 321, the JSDK platform 40 changes the state of the scan application 321 to the init state, and notifies the logging service 42 that the scan application 321 has changed to the init state (S121). The logging service 42 records the notified information as a temporary activation log 80.

  The temporary activation log 80 is recorded in a file with the following syntax, for example. FIG. 13 is a diagram for explaining an example of the syntax of the temporary activation log. In FIG. 13, the syntax of the temporary activation log for one line (for one recording) is described in a tree format. Each node of the tree indicates items constituting the temporary activation log.

  As shown in the figure, the provisional activation log 80 records a number as the first item, a date as the second item, a time as the third item, and an application name as the fourth item. The number is a number indicating the log recording order. The date and time are the date and time when the log is recorded. The application name is the application name of the temporarily activated application. However, the product ID may be used. Subsequently, the type of the recorded contents of the log is recorded in the fifth item. As the type, “Bundle”, “Memory”, “Scan”, “Panel”, or “hdd” is recorded.

  “Bundle” indicates that the log is related to the state transition of the bundle (application). In this case, for example, “initState” or “activeState” is recorded in the sixth item as the state of the bundle after the transition. “InitState” indicates an init state. “ActiveState” indicates an active state.

  “Memory” indicates a log relating to securing or releasing of memory. In this case, the total value of heap memory consumption by the application is recorded in the sixth item in the form of “Heap = <Size>”. In the seventh item, the total amount of consumption of the stack area by the application is recorded in the format of “Stack = <Size>”. In the eighth item, for example, “Object” is recorded as the type of the target for which the memory is newly secured. “Object” indicates an object. In the ninth item, a target type or class name for which a memory is newly secured and its size are recorded. In the drawing, “Heap”, “Stack”, and “Object” are described as having a selective relationship. However, as described above, each item is recorded in series.

  “Scan” indicates that the log is related to the operation of the scanner (imaging unit 121). In this case, as the sixth item, for example, “setup”, “start”, or “complete” is recorded as the type of operation related to the scanner. “Setup” indicates scanner setup. “Start” indicates the start of scanning. “Complete” indicates a successful scan. In the case of “setup”, a value (“attribute”) meaning attribute setting is recorded as the sixth item, and the seventh item is a monochrome scan (“mono”) or a color scan (“color”). It is recorded whether there is.

  “Panel” indicates that the log is related to the operation of the operation panel 202. In this case, for example, “show” is recorded as the operation type of the operation panel 202 in the sixth item. “Show” indicates display of information (screen or message) on the operation panel 202.

  “Hdd” indicates that the log is related to the operation of the HDD 233. In this case, in the sixth item, for example, “read” or “write” is recorded as the type of operation. “Read” indicates reading of information. “Write” indicates writing of information.

  FIG. 14 is a diagram illustrating a specific example of the temporary activation log. The temporary activation log 80 shown in FIG. 14 is an example recorded according to the syntax described in FIG. FIG. 14 shows an example in which the value of each item is recorded in a CSV (Comma Separated Values) format separated by commas. In the figure, the first line shows an example of a log recorded in response to the notification in step S121. That is, “0001” indicates the number, “2007.05.10” indicates the date, “11: 30: 24: 04” indicates the time, and “ScanApp” indicates the application name of the scan application 321. Show. In addition, since the fifth item is “Bundle” and the sixth item is “initState”, it can be seen that the log on the first line records that the scan application 321 has transitioned to the init state. .

  Returning to FIG. Following step S121, the JSDK platform 40 changes the state of the scan application 321 to the active state in response to the activation request of the scan application 321, and notifies the logging service 42 that the scan application 321 has changed to the active state ( S122). The logging service 42 records the notified information as a temporary activation log 80. Here, the log to be recorded corresponds to the second line in FIG. In FIG. 7, for the sake of convenience, the transition of the scan application 321 to the pause state is omitted.

  Subsequently, the JSDK platform 40 activates a bundle of scan applications 321 (S123). When activated, the scan application 321 acquires interface information of the service bundle 33 used by the scan application 321 itself from the JSDK platform 40 (S124). Here, interface information of the scan service 331 and the panel service 332 is acquired. The scan service 331 and the panel service 332 are activated when the multifunction machine 10 is activated, and interface information is registered in the JSDK platform 40 at that time.

  Subsequently, the scan application 321 generates an object (an instance of the ScanService class) of the scan service 331 necessary for using the scan service 331 based on the interface information of the scan service 331. Thereafter, the request notification from the scan application 321 to the scan service 331 is strictly performed through the object. Generation of an object of the service bundle 33 such as the scan service 331 is a target of access control by the security manager 41. Accordingly, the creation of the object of the scan service 331 is notified to the security manager 41 in the constructor of the object (S125). In response to the notification, the security manager 41 identifies the class name of the object generation source (scan application 321) and indicates that the memory is consumed by the scan application 321 together with the class name and the size of the object. (S126). The size of the object can be determined based on the class name. Note that how the security manager 41 identifies an object generation source will be described later.

  The logging service 42 records the notified information as a temporary activation log 80. Here, the log to be recorded corresponds to the third line in FIG. In the third line of FIG. 14, “Memory, Heap = 2 MB, Stack = 100 KB, Object, ScanService = 1 MB” is recorded. This indicates that the current total consumption of the heap memory by the scan application 321 is 2 MB, the current total consumption of the stack area is 100 KB, an object of the ScanService class is generated, and the size thereof is 1 MB.

  Subsequently, based on the interface information of the scan service 331, the scan application 321 sends initial settings (that is, initial settings for monochrome scan) for constructing a scan process corresponding to the behavior of the scan application 321 to the scan service 331. (S127). The scan service 331 attempts to notify the native service layer 60 of an initial setting request from the scan application 321 via the request path control unit 50 (S128). However, since the scan application 321 that is the initial setting request source is temporarily activated, the request path control unit 50 notifies the behavior service 335 without notifying the native service layer 60 of the initial setting request (S129). Note that how the request path control unit 50 determines whether or not the caller (here, the initial setting requester) is temporarily activated will be described later.

  The behavior service 335 performs emulation of the initial setting of the scanner, and notifies the request source (scan application 321) via the request path control unit 50. Here, it is notified that the initial setting has been normally performed according to the setting in the description 731 of the behavior script 73. Accordingly, the scan application 321 determines that the initial scan setting has been performed normally. If the scan application 321 is not temporarily activated (if it is activated), the request notified to the request path control unit 50 is notified to the native service layer 60, and the initial setting is actually performed.

  Subsequently, the behavior service 335 notifies the logging service 42 that the initial setting of the monochrome scan has been requested (S130). The logging service 42 records the notified information as a temporary activation log 80. Here, the log to be recorded corresponds to the fourth line in FIG. The behavior service 335 also notifies the scenario service 334 that the initial setting (emulation) of the monochrome scan has been completed (S131). The scenario service 334 is a service that functions as a pseudo operator of an application. Therefore, it cannot function until the operation screen 510a of the application is displayed on the operation panel 202. Therefore, the scenario service 334 does not start the execution of the definition contents of the scenario script 72 until the completion of drawing (display) of the operation screen 510a on the operation panel 202 is notified, and the notification from the behavior service 335 is not received. ignore.

  Note that the notification to the logging service 42 and the scenario service 334 by the behavior service 335 is a process executed by logic pre-installed in the behavior service 335 (not a process executed based on the behavior script 73). ). That is, when the service request whose path has been changed by the request path control unit 50 is notified, the behavior script 335 notifies the logging service 42 that the service request has been received, and the behavior service according to the service request. 335 is implemented so as to notify the scenario service 42 of the result of emulation.

  Subsequently, the scan application 321 generates an object (an instance of the PanelService class) of the panel service 332 necessary for using the panel service 332 based on the interface information of the panel service 332. Thereafter, the request notification from the scan application 321 to the panel service 332 is strictly performed through the object. The creation of the panel service 332 object is notified to the security manager 41 in the constructor of the object (S132). In response to the notification, the security manager 41 identifies the class name of the object generation source (scan application 321) and indicates that the memory is consumed by the scan application 321 together with the class name and the size of the object. (S133). The logging service 42 records the notified information as a temporary activation log 80. Here, the log to be recorded corresponds to the fifth line in FIG. In the fifth line of FIG. 14, “Memory, Heap = 3 MB, Stack = 300 KB, Object, Panel Service = 1 MB” is recorded. This indicates that the current total consumption of the heap memory by the scan application 321 is 3 MB, the current total consumption of the stack area is 300 KB, an object of the PanelService class is generated, and the size thereof is 1 MB.

  Subsequently, the scan application 321 notifies the panel service 332 of a drawing request of the operation panel 202 on the operation screen 510a of the scan application 321 using the interface information of the panel service 332 (S134).

  Subsequently, the panel service 332 constructs (generates) screen information to be notified to the native service layer 60 in order to cause the operation panel 202 to draw the operation screen 510 a of the scanner application 321, and the operation screen 510 a based on the screen information. A drawing request is to be notified to the native service layer 60 via the request path control unit 50 (S135). However, since the scanning application 321 that is the drawing request source of the operation screen 510a is temporarily activated, the request path control unit 50 does not notify the native service layer 60 of the drawing request but notifies the behavior service 335 together with the screen information. (S136).

  The behavior service 335 performs emulation of drawing of the operation screen 510a based on the screen information. As a result, the operation screen 510a is virtually drawn. Here, “virtually” means that the operation screen 510 a is not actually displayed on the operation panel 202. However, the screen information of the operation screen 510a is retained in the behavior service 335. Subsequently, the behavior service 335 notifies the request source (scan application 321) of the result of the emulation of the drawing on the operation screen 510a via the request path control unit 50. Here, it is notified that the drawing has been normally performed according to the setting in the description 732 of the behavior script 73.

  Subsequently, the behavior service 335 notifies the logging service 42 that the drawing of the operation screen 510a has been requested (S137). The logging service 42 records the notified information as a temporary activation log 80. Here, the log to be recorded corresponds to the sixth line in FIG. The behavior service 335 also notifies the scenario service 334 that drawing (emulation) of the operation screen 510a has been completed (S138).

  In response to the notification of completion of drawing on the operation screen 510a, the scenario service 334 starts processing according to the definition content of the scenario script 72. First, an object of the start button 512 (hereinafter referred to as “start button object”) in the operation screen 510a (FIG. 11) is acquired based on the description 721 of FIG. The start button object is one of objects constituting the screen information of the operation screen 510, and is acquired from the behavior service 335 in response to a function call described in the description 721. Subsequently, based on the function described in the description 722, the process waits for the time (3 seconds) specified in the argument of the function. Subsequently, based on the description 723, a message indicating that the start button 512 has been pressed is notified to the request path control unit 50 (S139). The reason for waiting for 3 seconds before notifying that the start button 512 is pressed is to make the pseudo operation input by the scenario service 334 closer to the operation input by the actual user. That is, the actual user does not press the start button 512 immediately after the operation screen 510a is displayed, and starts the operation input after about 3 seconds.

  Subsequently, the scenario service 334 acquires an object of the Result label 513 (hereinafter referred to as “Result label object”) on the operation screen 510 based on the description 724 of the scenario script 72. The Result label object is one of the objects constituting the screen information of the operation screen 510 and is acquired from the behavior service 335 in response to a function call described in the description 724.

  Subsequently, the scenario service 334 is in a standby state until the Result label 513 is updated based on the description 725 of the scenario script 72. Therefore, the processing after the description 726 is not executed at this stage.

  On the other hand, in step S139, the request path control unit 50 that has received a message notifying that the start button 512 has been pressed from the scenario service 334 notifies the panel service 332 of the message (S140).

  The panel service 332 receives the notification of pressing the start button 512 and notifies the scan application 321 that the start button 512 has been pressed (S141). Upon receiving a notification that the start button 512 has been pressed, the scan application 321 requests the scan service 331 to start scanning (S142). The scan service 331 attempts to notify the native service layer 60 of a scan start request from the scan application 321 via the request path control unit 50 (S143). However, since the scan application 321 that is the request source of the scan start is temporarily activated, the request path control unit 50 notifies the behavior service 335 without notifying the scan start request to the native service layer 60 (S144).

  Subsequently, the behavior service 335 notifies the logging service 42 that the start of scanning has been requested (S145). The logging service 42 records the notified information as a temporary activation log 80. Here, the log to be recorded corresponds to the seventh line in FIG. The behavior service 335 also notifies the scenario service 334 that scanning is started (S146). Here, since the scenario service 334 is waiting for the update of the Result label 513, nothing is performed.

  Subsequently, the behavior service 335 performs scan emulation and notifies the request route control unit 50 of the processing result (S147). Here, according to the setting in the description 731 of the behavior script 73, a message indicating that the scan has been performed normally (normal end) is notified. The behavior service 335 also notifies the logging service 42 and the scenario service 334 that scanning has ended normally (S148, S149). The logging service 42 records the notified information as a temporary activation log 80. Here, the log to be recorded corresponds to the eighth line in FIG. Further, since the scenario service 334 is waiting for the update of the Result label 513, nothing is performed in response to the notification of the normal end of the scan.

  On the other hand, in step S147, the request path control unit 50 that receives the message notifying the normal end of the scan from the behavior service 335 notifies the scan service 331 of the message (S150). The scan service 331 notifies the scan application 321 that is the request source of the scan start of the normal end of the scan (S151).

  In response to the notification of the normal end of scanning, the scan application 321 requests the panel service 332 to display the character string “Complete” on the Result label 513 of the operation screen 510 (S152). In response to the request from the scan application 321, the panel service 332 attempts to notify the native service layer 60 of a display request for the character string “Complete” via the request path control unit 50 (S153). However, since the scan application 321 that is the request source of the display request for the character string “Complete” is temporarily activated, the request path control unit 50 does not notify the native service layer 60 of the display request for the character string “Complete”. The behavior service 335 is notified (S154).

  The behavior service 335 virtually displays the character string “Complete” on the Result label 513. Specifically, the display processing of the character string “Complete” is emulated by setting the character string “Complete” for the Result label object in the stored screen information. Subsequently, the behavior service 335 notifies the request source (scan application 321) of the emulation result via the request path control unit 50. Here, according to the setting in the description 732 of the behavior script 73, it is notified that the character string “Complete” has been normally displayed.

  Subsequently, the behavior service 335 notifies the logging service 42 that the update of the operation screen 510 is requested (S155). The logging service 42 records the notified information as a temporary activation log 80. Here, the log to be recorded corresponds to the ninth line in FIG. The behavior service 335 also notifies the scenario service 334 that the character string “Complete” is displayed in the Result label 513 (S156).

  In response to the notification, the scenario service 334 returns from the standby state until the Result label 513 is updated, and the character string displayed in the Result label 513 is based on the description 726 of the scenario script 72 (FIG. 10). , “Complete” is determined. When the character string displayed in the Result label 513 is “Complete”, the scenario service 334 indicates that the application (scan application 321) that is temporarily activated based on the description 727 operates according to the scenario ( (Success of scenario) is notified to the temporary activation service 333 (S157). On the other hand, when the character string displayed in the Result label 513 is not “Complete”, the scenario service 334 indicates that the application that is the target of provisional activation did not operate according to the scenario based on the description 728 ( Scenario failure) is notified to the temporary activation service 333.

  When the provisional activation service 333 receives notification of the success of the scenario, the provisional activation service 333 logs the retrieval of the provisional activation log of the application (scan application 321) whose application name is “ScanApp” based on the description 712 of the main script 71 (FIG. 9). Request to service 42. Based on the application name, the logging service 42 searches the provisional activation log 80 for the provisional activation log of the scan application 321 and notifies the provisional activation service 333 of the search result (S159). In the temporary activation log 80 of FIG. 14, an example in which only log information of the scan application 321 is recorded is shown. Therefore, here, the contents up to the ninth line of the provisional activation log 80 shown in FIG. 14 are notified to the provisional activation service 333 as they are.

  Subsequently, the provisional activation service 333 determines whether the provisional activation is successful based on the description 713 of the main script 71 (FIG. 9). In the description 713, the conditions for successful temporary activation are that the consumed memory is 5 MB or less, the HDD 233 is not written, and the scan mode is monochrome. Therefore, the provisional activation service 333 searches the provisional activation log 80 for the maximum value in the heap memory consumption log recorded in the format of “Memory, Heap = xxx MB”. Check whether the maximum value is 5 MB or less. The provisional activation service 333 searches the provisional activation log 80 for a description such as “hdd, write” and confirms whether or not the HDD 233 is written. Further, the provisional activation service 333 searches the provisional activation log 80 for a description such as “Scan, setup, attribute, mono” and confirms whether the scan mode is monochrome.

  According to the temporary activation log 80 in the present embodiment, the maximum value of heap memory consumption is 3 MB from the fifth line, which is 5 MB or less. Further, there is no description such as “hdd, write”, and writing to the HDD 233 is not performed. Further, there is a description such as “Scan, setup, attribute, mono” on the fourth line, and the scan mode is monochrome. Accordingly, the temporary activation success condition is satisfied. Therefore, the provisional activation service 333 notifies the SAS manager 31 that the provisional activation has been successful based on the description 714 of the main script 71 (S160).

  The SAS manager 31 receives the notification of successful temporary activation and requests the JSDK platform 40 to terminate the scan application 321 that is temporarily activated (S161). The JSDK platform 40 notifies the logging service 42 that the scan application 321 is transitioned to the destroy state (S162). The logging service 42 records the notified information as a temporary activation log 80. Here, the log to be recorded corresponds to the 10th line in FIG. Subsequently, the JSDK platform 40 ends the scan application 321 (S163).

  On the other hand, after requesting termination of the scan application 321 in step S161, the SAS manager 31 displays on the operation panel 202 that the installation of the scan application 321 is completed (S164). With this display, the operator recognizes that the scan application 321 has been normally installed (S165). Therefore, in order to use the scan application 321, the operator inputs an instruction for full activation of the scan application 321 via the operation panel 202 (S166). The instruction to start the scan application 321 is notified to the SAS manager 31 (S167). The SAS manager 31 requests the JSDK platform 40 to fully activate the scan application 321 (S168). The JSDK platform 40 activates the scan application 321 (S169).

  Thereafter, a request from the activated scan application 321 is notified to the native service layer 60 by the request route control unit 50 without changing the route. Therefore, the operation screen is actually displayed, and scanning is executed in response to an input from the operator via the operation screen.

  Note that when provisional activation fails, for example, when provisionally activated scan application 321 does not operate according to the scenario, or when provisional activation success conditions (description 713 of main script 71) are not satisfied. In step S160, the provisional activation service 333 notifies the SAS manager 31 of the provisional activation failure based on the description 715 of the main script 71 (FIG. 9). In response to the notification, the SAS manager 31 displays on the operation panel 202 that the installation of the scan application 321 has failed, and invalidates the installation of the scan application 321. Therefore, the operator cannot fully activate (actually use) the scan application 321.

  Next, how the security manager 41 identifies the object generation source in step S126 and the like will be described. FIG. 15 is a diagram for explaining a method of identifying an object generation source by the security manager. FIG. 15 illustrates an example in which an object of the scan service 331 is generated by the scan application 321. Therefore, it corresponds to steps S125 and S126 in FIG.

  In the figure, “ScanApp” is the class name of the scan application 321. “ScanService” is the class name of the scan service 331. “A: ScanApp” indicates an object a of the ScanApp class (that is, the instantiated scan application 321). “B: ScanService” indicates an object b of the ScanService class (that is, the instantiated scan service 331).

  When the object a calls the constructor of the ScanService class to generate the object b (S21), the class name (“ScanApp”) of the object a is stored in the stack (S22). When the object b calls the security manager 41 in its constructor (S23), the class name of the object b (“ScanService”) is stored in the stack (S24). The security manager 41 traces the inside of the stack in response to the call from the object b, thereby identifying that the caller class name is “ScanApp”, that is, the generation source of the object b is the scan application 321. (S25).

  Next, how the request path control unit 50 determines whether or not the call request source application of the native service layer 60 is temporarily activated in step S129 or the like will be described. First, as a premise, an application that is temporarily activated is registered in the request route control unit 50 in advance (for example, step S116). Therefore, if the application name of the call request source can be identified in the request path control unit 50, it can be determined whether or not the application is temporarily activated.

  In the present embodiment, the application bundle 32 that is the JSDK application 30 is a target for temporary activation. Here, the JSDK application 30 is a Java (registered trademark) application. Therefore, for example, an application can be identified using a thread group (ThreadGroup) which is a standard class of Java (registered trademark). A thread group is a set of threads or thread groups, and one or more threads can be associated with a thread group. A name (thread group name) can be added to the thread group. In each thread, the thread group to which the thread belongs can be identified. In the present embodiment, the application bundle 32 and the service bundle 33 are implemented as “bundles”, but a bundle is a library (a set of functions or classes) that can be dynamically linked. Further, the request path control unit 50 is also a library (a set of functions or classes). Therefore, none of them is started as a process, and the called side operates on the calling thread.

  Based on such a mechanism, the request path control unit 50 can identify the caller application name as follows. FIG. 16 is a diagram for explaining a method of identifying a caller application name using a thread group. In FIG. 16, for convenience, the vertical relationship of each module is different from that in FIG.

  In the figure, GPx (x is a to c) indicates a thread group. thx (x is ad) indicates a thread. In the example of FIG. 16, the scan application 321 is associated with the thread group GPb, and the application name of the scan application 321 is added as the thread group name. The scan service 331 is associated with a thread group GPc.

  The scan application 321 includes a thread tha executing the method A and a thread thb executing the method B. Here, the thread tha and the thread thb belong to the thread group GPb. For example, when the method C of the scan service 331 is called from within the method B of the scan application 321, the method C operates on the thread thb. Further, when the function D of the request path control unit 50 is called from the method C, the function D operates on the thread thb. Accordingly, when the current thread is confirmed in the function D, the thread thb is specified, and when the thread group to which the thread thb belongs is further confirmed, the thread group GPb is specified. Therefore, by acquiring the thread group name of the thread group GPb in the function B, the application name of the caller of the function B (that is, the request path control unit 50) is acquired. Further, by comparing the acquired application name (thread group name) with the pre-registered application name that is temporarily activated, it is determined whether or not the function B caller is temporarily activated. Can do.

  However, a thread group is not necessarily used as a method for identifying a caller application. For example, the application name of the caller may be inherited by an argument of each method or each function.

  As described above, according to the MFP 10 in the first embodiment, before an application is actually used, the application is temporarily activated and a log (temporary activation log 80) relating to the behavior is recorded. Keep it. Based on the temporary activation log 80, it is possible to confirm for each application whether or not a preset restriction is satisfied. Therefore, it is possible to prevent the operation of the application that does not satisfy the preset restriction, and to reduce the possibility of the unauthorized operation by the application.

  In addition, the criteria for determining the success or failure of provisional activation, the operation contents of the application at the time of provisional activation, and the behavior of the behavior service 335 at the time of provisional activation are the provisional activation script 70 (main script 71, scenario) that is a file separated from the program. The script 72 and the behavior script 73) are defined. Therefore, it is possible to easily change these pieces of information (judgment criteria, operation details, behavior, etc.) in accordance with changes in the resources of each application and multifunction device 10 (for example, addition of memory, etc.). In particular, if the file is in a text format as in this embodiment, the change is easy.

  Further, since the behavior service 335 responds to the application as the native service layer 60 (in the same format as the native service layer 60), the application does not need to be aware of whether or not it is provisional activation. Therefore, it is not necessary to mount each application again in order to realize provisional activation.

  During the temporary activation, the native service layer 60 is not called, and hardware unique to the multifunction machine 10 (for example, hardware for performing image processing) is not used. Therefore, the temporary activation may be performed by a computer such as a general PC (Personal Computer). In this case, the computer need only be able to operate software other than the native service layer 60 in FIG.

  Next, a second embodiment will be described. In the first embodiment, based on the temporary activation log 80, it is determined whether or not the consumed memory is within the limit value (5 MB) for each application. However, when a plurality of applications are started in parallel, the determination in the first embodiment may not be sufficient.

  FIG. 17 is a diagram for explaining how the memory is consumed when a plurality of applications are activated in parallel.

  In FIG. 17, (A) shows the relationship between the passage of time (application state transition) and the maximum value of heap memory consumption due to an application bundle 32 (hereinafter referred to as “application A”). It is. As illustrated, the application A consumes a maximum of 3 MB, 1 MB, and 4 MB of heap memory in each of the init state, the pause state, and the active state. In this case, the maximum consumption of the heap memory of the application A is 4 MB throughout the entire state, which satisfies the limit of 5 MB in the first embodiment. Therefore, for application A, the provisional activation is determined to be successful, and the actual activation is possible.

  In the figure, (B) shows the relationship between the passage of time (application state transition) and the maximum amount of heap memory consumption by an application bundle 32 (hereinafter referred to as “application B”) different from application A. It is a thing. As illustrated, the application B consumes 3 MB, 1 MB, and 1 MB of heap memory at the maximum in each of the init state, the pause state, and the active state. In this case, the maximum consumption of the heap memory of the application B is 3 MB throughout the entire state, which satisfies the limit of 5 MB in the first embodiment. Therefore, it is determined that the provisional activation is also successful for the application B, and the actual activation is possible.

  (C) in the figure shows the relationship between the passage of time and the maximum heap memory consumption when application A and application B are activated simultaneously. That is, when two applications permitted to be activated are activated at the same time and state transition is performed at the same timing, the maximum number of 3 + 3 in each of the init state, the pause state, and the active state by the two applications. = 6 MB, 1 + 1 = 2 MB, 1 + 4 = 5 MB of heap memory is consumed. Then, in the init state, the limit value of 5 MB is exceeded, and the application may not operate normally.

  Therefore, in the second embodiment, an example in which such a problem is solved will be described. In the second embodiment, only differences from the first embodiment will be described. Therefore, the points not particularly mentioned may be the same as those in the first embodiment.

  In the second embodiment, the main script 71 is defined as follows. FIG. 18 is a diagram illustrating a description example of the main script in the second embodiment. In FIG. 18, the same parts as those in FIG. 9 are denoted by the same reference numerals, and the description thereof is omitted. In the second embodiment, the main script 71 will be described as the main script 71a.

  The main script 71a is different in description 716 from the first embodiment. That is, in the description 716, the interface of the script function pbCase1 is defined, but in the second embodiment, a variable (PseudoBootLog log) for storing the temporary activation log is defined as an OUT type argument passed by reference. Yes. The value of the argument is stored in the description 712.

  The processing procedure related to the temporary activation of the multifunction machine 10 in the second embodiment is almost the same as that in FIG. However, based on the description 716 in the main script 71a, in step S160, the provisional activation service 333 notifies the SAS manager 31 of the contents of the provisional activation log 80 together with information indicating the success or failure of the provisional activation. The SAS manager 31 associates the notified temporary activation log 80 with the application bundle 32 (scan application 321 in the example of FIG. 7) that has been the target of temporary activation, and stores and manages it in the HDD 233, for example. The association may be performed, for example, by setting the file name of the temporary activation log 80 as the application name of the application bundle 32.

  In the second embodiment, the processing related to the management of the application being activated (including when the activation is started) by the SAS manager 31 when receiving the application activation request in step S167 is also different.

  FIG. 19 is a flowchart for explaining management processing of an active application by the SAS manager according to the second embodiment. Note that the processing in FIG. 19 is performed for the main activation application (that is, the application whose provisional activation has succeeded).

  When an application (hereinafter referred to as “app A”) that requires state transition (including transition to the init state due to activation) occurs in the multifunction machine 10 (Yes in S201), the SAS manager 31 The sum of the maximum value of the memory consumption in the previous state and the maximum value of the memory consumption in each state of the other currently active applications is equal to or less than a preset limit value (for example, 5 MB). It is determined whether or not (S202).

  Note that the SAS manager 31 stores the maximum memory consumption amount of the transition state of the application A and the maximum memory consumption amount of the current state of each application in the temporary activation log 80 associated with each application. Judgment based on. Further, the SAS manager 31 detects the occurrence of an application that changes state by a notification from the application.

  If the sum of the maximum values of the memory consumption is equal to or less than the limit value (Yes in S202), the SAS manager 31 permits the state transition of the app A. As a result, the application A performs state transition (S203). On the other hand, if the total memory consumption exceeds the limit value (No in S202), the SAS manager 31 waits for the state transition of the app A and information indicating that the state transition of the app A is waiting ( Hereinafter, “standby information”) is registered in the state transition standby queue. The standby information includes, for example, identification information of the app A and identification information of the transition destination state. However, the standby information may include the maximum memory consumption amount of the transition destination state instead of the identification information of the transition destination state. By doing so, it is possible to omit the process of referring to the temporary activation log 80 again for the memory consumption of the transition destination state of the application A. The state transition standby queue is a queue or list of standby information. That is, a list of applications waiting for state transition can be grasped by the state transition waiting queue.

  When the state transition of the application A is performed in step S203, the sum of the maximum values of the memory consumption amounts of the respective states of the respective applications changes due to the state transition of the application A. Therefore, there is a possibility that the state transition of the state transition waiting application can be permitted. Therefore, the SAS manager 31 executes the processing after step S205.

  That is, the SAS manager 31 determines the presence / absence of an application waiting for a state transition by confirming the presence / absence of waiting information in the state transition waiting queue (S205). When there is no application waiting for state transition (when the state transition waiting queue is empty) (No in S205), the process returns to step S201.

  On the other hand, when there is an application waiting for state transition (Yes in S205), the SAS manager 31 extracts one piece of standby information from the state transition standby queue (S206). The order in which standby information is extracted from the state transition standby queue may be in accordance with FIFO (First-In First-Out) or LRU (Least Recently Used), or priorities may be given to applications and the priority may be followed. The priority order may be recorded in advance in the HDD 233 or the like.

  Subsequently, the SAS manager 31 determines the maximum memory consumption amount in the transition destination state of the application related to the extracted standby information (hereinafter referred to as “current standby information”) and the memory consumption in each state of other applications. It is determined whether or not the sum of the maximum value and the amount is equal to or less than a preset limit value (S207).

  When the sum of the maximum values of the memory consumption is equal to or less than the limit value (Yes in S207), the SAS manager 31 deletes the current standby information from the state transition standby queue (S208), and displays the state of the application that has been waiting for the state transition. A transition is made (S203). In addition, in order to further determine whether or not the state transition of another application waiting for state transition can be made in accordance with the state transition of the application, processing subsequent to step S205 is executed.

  On the other hand, if the sum of the maximum memory consumption exceeds the limit value in step S207 (No in S207), the process returns to step S201. However, you may make it return to step S206. In this case, among the applications whose standby information is registered in the state transition standby queue, the state transition of the application that can transition within the limit value is preferentially executed.

  As described above with reference to FIG. 19, it is possible to avoid the situation described with reference to FIG. 17 by restricting the state transition of the application. The example of FIG. 17 is improved as follows. FIG. 20 is a diagram illustrating a state in which the memory consumption is appropriately managed by the state transition restriction.

  In FIG. 20, when the init state of app A and the init state of app B overlap, the limit value (5 MB) is exceeded. Therefore, the transition to the init state of app A is performed after the transition to the pause state of app B. It has been broken. By doing so, the total value of the consumed memory of the application A and the application B is suppressed within the limit value throughout the entire process.

  As described above, according to the MFP 10 in the second embodiment, even when a plurality of applications operate in parallel, they are recorded in the temporary startup log 80 recorded during the temporary startup of each application. The behavior (behavior) of the application can be changed based on the information obtained. In other words, the total value of memory consumption by a plurality of applications can be maintained below a preset limit value. Therefore, the possibility of unauthorized operation by the application can be reduced.

  In the second embodiment, an example in which it is determined whether or not the maximum value of the memory consumption through all states is equal to or less than the limit value at the time of provisional activation (main script 71a (FIG. 18). ) Description 713). Accordingly, the processing procedure of FIG. 19 has been described on the assumption that only applications that satisfy the restriction are targeted for actual activation. However, when the application is fully activated, the SAS manager 31 refers to the temporary activation log 80 of the application to determine the maximum value of memory consumption through all the states, and the maximum value is the limit value. If it exceeds, the actual activation of the application may be rejected. In this case, it is not always necessary to check the maximum memory consumption at the time of provisional activation. That is, the description “log.Maxmem <5 MB” in the description 713 of the main script 71a may be deleted.

  19 may be performed by the JSDK platform 40.

  By the way, in the above, the example which uses temporary starting as a means for a prior check of the suitability of an application was demonstrated. However, the purpose of temporary activation is not limited to this. For example, it can be used as a means for analyzing the cause of a failure that has occurred during the actual activation of an application. Hereinafter, examples in which provisional activation is applied to failure cause analysis will be described as third and fourth embodiments.

  FIG. 21 is a diagram for explaining a failure analysis method using temporary activation according to the third embodiment. In FIG. 21, the failure handling server 20 is a computer that is connected to the multifunction device 10 via a network such as the Internet and remotely monitors the multifunction device 10. The failure handling server 20 is operated by, for example, the vendor of the multifunction machine 10.

  In response to an instruction from the operator, the SAS manager 31 of the multifunction peripheral 10 activates an application (for example, the scan application 321) (S301). When a failure occurs during the actual activation of the application, the panel service 332 displays a warning screen notifying that the failure has occurred on the operation panel 202 (S302). Subsequently, the SAS manager 31 transmits information (for example, an error code) indicating the failure content to the failure handling server 20 (S303).

  The failure handling server 20 transmits a temporary activation script 70 appropriate for investigating the cause of the failure to the multifunction machine 10 based on the information indicating the failure content (S304). For example, a temporary activation script 70 suitable for investigating the cause of the failure content is stored in advance in the storage device of the failure response server 20 for each application and for each failure content. The temporary activation script 70 suitable for investigating the cause of the failure content includes a scenario script 72 in which an appropriate scenario is defined for analyzing the failure, and an appropriate emulation content for analyzing the failure. A temporary activation script 70 that includes a defined behavior script 73.

  The multifunction machine 10 temporarily activates the application in which the failure has occurred by using the received temporary activation script 70 (S305). The processing procedure at this time is as described in FIG. As a result, a temporary activation log 80 is generated. Therefore, the SAS manager 31 of the multifunction machine 10 transmits the temporary activation log 80 to the failure handling server 20 (S306).

  The failure handling server 20 analyzes the temporary activation log 80 and identifies the cause. The identification of the cause may be performed automatically or manually. When the cause is specified, the operator is notified of the failure analysis result (S307). The report may be automatically performed by e-mail or the like. Further, when the bug is an application, a corrected version may be remotely installed from the failure response server 20 to the multifunction machine 10.

  The temporary activation script 70 for each failure content may be stored in the multifunction device 10 in advance, and cause analysis may be performed on the multifunction device 10 side. In this case, the failure handling server 20 is not always necessary.

  Next, a fourth embodiment will be described. FIG. 22 is a diagram for explaining a failure analysis method using temporary activation according to the fourth embodiment. In FIG. 22, the same parts as those of FIG. In the fourth embodiment, it is assumed that the JSDK application 30, the JSDK platform 40, the request path control unit 50, and the like are mounted on the failure handling server 20.

  In FIG. 22, steps S401 to S403 are the same as steps S301 to S303 in FIG.

  Subsequently, the failure handling server 20 selects an appropriate temporary activation script 70 from the storage device for investigating the cause of the failure based on the information indicating the failure content (S404). Subsequently, the failure handling server 20 uses the temporary startup script 70 to temporarily start the application in which the failure has occurred, analyzes the temporary startup log 80 generated as a result, and identifies the cause. When the cause is specified, the failure handling server 20 reports the failure analysis result to the operator (S406). If the bug is an application bug, the correction plate may be remotely installed in the multifunction machine 10 from the failure handling server 20.

  As described above, by executing the temporary activation of the application based on the temporary activation script 70 corresponding to the failure, the cause can be appropriately analyzed based on the temporary activation log 80 generated as a result.

  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.

It is a figure for demonstrating the outline | summary of 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 example of mounting of the state transition model of an application bundle or a service bundle. It is a figure for demonstrating the main functions of a request path | route control part. It is a figure for demonstrating a temporary start script and a temporary start service. FIG. 6 is a sequence diagram for explaining a processing procedure related to provisional activation of the multifunction peripheral according to the first embodiment. It is a figure which shows the example of the application information currently recorded on the application management file of the scan application. It is a figure which shows the example of a description of the main script in 1st embodiment. It is a figure which shows the example of a description of the scenario script in 1st embodiment. It is a figure which shows the example of the operation screen of a scan application. It is a figure which shows the example of a description of the behavior script in 1st embodiment. It is a figure for demonstrating the example of the syntax of a temporary starting log. It is a figure which shows the specific example of a temporary starting log. It is a figure for demonstrating the identification method of the origin of the object by a security manager. It is a figure for demonstrating the identification method of the caller's application name using a thread group. It is a figure for demonstrating the mode of consumption of the memory at the time of starting a some application in parallel. It is a figure which shows the example description of the main script in 2nd embodiment. It is a flowchart for demonstrating the management process of the application in process by the SAS manager in 2nd embodiment. It is a figure which shows a mode that memory consumption is managed appropriately by the restriction | limiting of a state transition. It is a figure for demonstrating the method of the failure analysis using temporary starting in 3rd embodiment. It is a figure for demonstrating the method of the failure analysis using temporary starting in 4th embodiment.

Explanation of symbols

10 MFP 30 JSDK application 31 SAS manager 32 Application bundle 33 Service bundle 40 JSDK platform 50 Request path control unit 60 Native service layer 70 Temporary activation script 80 Temporary activation log 121 Imaging unit 122 Printing unit 201 Controller 202 Operation panel 203 Facsimile control unit 211 CPU
212 ASIC
221 NB
222 SB
231 MEM-P
232 MEM-C
233 HDD
234 Memory card slot 235 Memory card 241 NIC
242 USB device 243 IEEE 1394 device 244 Centronics device 321 Scan application 331 Scan service 332 Panel service 333 Temporary activation service

Claims (15)

An image forming apparatus capable of executing a program,
Script data acquisition means for acquiring script data corresponding to the content of the failure in response to detection of the occurrence of a failure in the program;
Starting means for starting the program after obtaining the script data;
Operating means for generating an input to the program based on the script data;
The content of the usage request or the content of the consumption is recorded in the storage device as log information in response to the occurrence of at least one of the usage request for the predetermined function of the image forming apparatus and the consumption of the predetermined resource by the program. An image forming apparatus comprising: a log recording unit. The script data acquisition means includes
In response to detecting the occurrence of a failure in the program, failure information transmitting means for transmitting information indicating the content of the failure to a computer connected via a network;
The image forming apparatus according to claim 1, further comprising: a receiving unit that receives script data returned according to the content of the failure.   The image forming apparatus according to claim 2, further comprising log information transmission means for transmitting the log information to the computer.   A response means for responding to the use request based on the script data in place of the function realization means for realizing the predetermined function in response to the use request for the predetermined function by the program. Item 4. The image forming apparatus according to any one of Items 1 to 3. Receiving means for receiving information indicating the content of the failure of the program from an image forming apparatus connected via a network;
Script data acquisition means for acquiring script data according to the content of the failure from the storage means;
Operating means for generating an input to the program based on the script data;
The content of the usage request or the content of the consumption is recorded in the storage device as log information in response to at least one of the usage request of the predetermined function of the image forming apparatus and the consumption of the predetermined resource by the program. An information processing apparatus comprising log recording means. A failure analysis support method executed by an image forming apparatus capable of executing a program,
A script data acquisition procedure for acquiring script data corresponding to the content of the failure in response to detection of the occurrence of a failure in the program;
An activation procedure for activating the program after obtaining the script data;
An operation procedure for generating an input to the program based on the script data;
The content of the usage request or the content of the consumption is recorded in the storage device as log information in response to at least one of the usage request for the predetermined function of the image forming apparatus and the consumption of the predetermined resource by the program. A failure analysis support method comprising a log recording procedure. The script data acquisition procedure includes:
In response to detecting the occurrence of a failure in the program, a failure information transmission procedure for transmitting information indicating the content of the failure to a computer connected via a network;
The failure analysis support method according to claim 6, further comprising: a reception procedure for receiving script data returned according to the content of the failure.   The failure analysis support method according to claim 7, further comprising a log information transmission procedure for transmitting the log information to the computer.   A response procedure for responding to the use request based on the script data instead of a function realization procedure for realizing the predetermined function in response to a use request for the predetermined function by the program. Item 9. A failure analysis support method according to any one of Items 6 to 8. A failure analysis support method executed by a computer,
A receiving procedure for receiving information indicating the content of a program failure from an image forming apparatus connected via a network;
Script data acquisition procedure for acquiring script data corresponding to the content of the failure from a storage device;
An operation procedure for generating an input to the program based on the script data;
The content of the usage request or the content of the consumption is recorded in the storage device as log information in response to at least one of the usage request for the predetermined function of the image forming apparatus and the consumption of the predetermined resource by the program. A failure analysis support method comprising a log recording procedure. In the image forming apparatus that can execute the program,
A script data acquisition procedure for acquiring script data corresponding to the content of the failure in response to detection of the occurrence of a failure in the program;
An activation procedure for activating the program after obtaining the script data;
An operation procedure for generating an input to the program based on the script data;
The content of the usage request or the content of the consumption is recorded in the storage device as log information in response to the occurrence of at least one of the usage request for the predetermined function of the image forming apparatus and the consumption of the predetermined resource by the program. Failure analysis support program for executing log recording procedure. The script data acquisition procedure includes:
In response to detecting the occurrence of a failure in the program, a failure information transmission procedure for transmitting information indicating the content of the failure to a computer connected via a network;
12. The failure analysis support program according to claim 11, further comprising: a reception procedure for receiving script data returned according to the content of the failure.   13. The failure analysis support program according to claim 12, further comprising a log information transmission procedure for transmitting the log information to the computer.   A response procedure for responding to the use request based on the script data instead of a function realization procedure for realizing the predetermined function in response to a use request for the predetermined function by the program. Item 14. A failure analysis support program according to any one of Items 11 to 13. On the computer,
A receiving procedure for receiving information indicating the content of a program failure from an image forming apparatus connected via a network;
Script data acquisition procedure for acquiring script data according to the content of the failure from a storage device;
An operation procedure for generating an input to the program based on the script data;
The content of the usage request or the content of the consumption is recorded in the storage device as log information in response to at least one of the usage request of the predetermined function of the image forming apparatus and the consumption of the predetermined resource by the program. Failure analysis support program for executing log recording procedure.

Images