JP2006146693A - Application management method and its control program - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To simplify application control in a system having a plurality of application modes. <P>SOLUTION: This application management system is provided with an ID applying means for applying unique ID to an application, a transition control means for controlling the transition of an application mode defined for each of functions where the control objects of an application are clearly different, a system status transition control means for controlling the transition of a system status defined commonly to the application and a system status management stack for managing the system status. An event patch means for receiving an event when an event is generated notifies the application depending on a notification method stored in the management stack. When a factor necessary for the mode transition is detected, the system status transition control means pushes and adds the stack when transition conditions are satisfied, and operates transition request queuing when the transition conditions are not satisfied. <P>COPYRIGHT: (C)2006,JPO&NCIPI

Description

  The present invention relates to an application management system such as a so-called multifunction printer having a plurality of functions.

  Since control software for conventional PC printers is created mainly for mechanism control functions, control related to the user interface and print source differences (word processor documents, digital camera photos, scanned images from scanners, etc.) ) All of the advanced control such as sequence switching caused by (2) is left to the PC application (see, for example, Patent Document 1).

  However, in recent years, with the widespread use of digital cameras and the like, there has been an increasing need for higher functionality for printers as output media. In addition to conventional printing functions from PCs, direct printing functions from digital cameras and Multifunction printers that can meet all printing needs, such as copy functions or fax functions, have been introduced to the market. Unlike conventional PC printers, multi-function printers with such complex functions require an advanced user interface and functions that can be used stand-alone. You have to do it yourself. The function required for a multi-function printer is by no means a single thing, and it is natural that it will change depending on the market target, so the software structure has the flexibility to add and delete functions. For this purpose, it is necessary to have a configuration in which individual applications modularized for each function can be connected to a flight.

The following elements are important in order to enhance the modularity of the application and make it extensible.
1. Even in different applications, the events generated from common resources such as key events should be unified and handled by a common interface. (Scalability)
2. In order to handle events generated from common resources efficiently, the system must have a management mechanism that limits the applications that should receive the events. (Processing efficiency)
3. The application must be configured to perform only the control necessary to realize each function (printing from a camera, copy printing, etc.). (Maintenance)
If the above 1 is not satisfied, the module that throws the event must change the control according to the application, and the expandability cannot be maintained. If 1 is satisfied but 2 is not satisfied, all applications are started in a round robin manner, and the overhead for control increases. If 3 is not satisfied, the application must control elements common to each function (for example, control when an error occurs).
JP 09-006408 A JP 07-175671 A

  However, RTOS such as Itron, which is generally used in embedded devices such as printers, is different from OS on a PC, and UI-related common events such as key events are efficiently handled for application processes operating in parallel. Since there is no window system mechanism for handling, there is a disadvantage that the above-described elements 1 and 2 cannot be satisfied as it is.

  As an example of a technique for managing a process by a subsystem other than the OS, for example, as disclosed in Patent Document 2, an operating process is introduced by introducing a subsystem called a “process management process” between the OS and the process. A method for managing the above has been proposed. If this method is applied, the above-described two elements can be realized by appropriately setting the “operation condition” described in the document, but the elements 1 and 3 cannot be satisfied.

  The present invention has been made to solve the above-described problems, and has the following features.

An application management method in a system having a plurality of application modes or a multi-function printer system,
A system state management stack, an event dispatch step for event dispatch,
A transition control step for performing application mode transition control, a transition control step for performing system state transition control, an event queuing step for performing transition request event queuing, an ID providing step for performing ID assignment,
It is characterized by providing.

  The “application mode” represents one mode defined for each function whose control target is clearly different. For example, “Direct print function from digital camera”, “Print function from storage device connected to any I / F”, “Print function via PC driver”, “Direct printing while reading image from scanner” The “copy printing function to be performed” generally requires different controls, and each is considered to form one application mode. On the other hand, “system state” is a state in which a common concept can be defined for each application mode. For example, “error state” corresponds to “system state”. (Note that the “idle state” is defined as a common concept in all modes. This state is the “base state” in the mode, and in principle is controlled by the process managing the application mode.) The module (task) for managing each application mode is simply referred to as “application”, and the module (task) for managing each system state is referred to as “system state management module”.

  According to the present application, the modularity of individual modules can be improved by introducing an application management system in a multi-function system having a plurality of functions and unifying the interface of the event transmission system. As a result, the expandability of the system is improved. There is an effect that can be.

  In addition, by introducing the concept of system state that is defined in common across multiple application modes and performing control in one system state across modes in one module, the reusability of the module increases, and as a result This has the effect of improving system design productivity.

  Further, since the transition between the system states is performed only by a simple stack push / pop operation, the load on the transition can be minimized. Furthermore, when the transition request is not satisfied, an internal queuing mechanism works, and when the state changes, it has a mechanism that searches the queue and automatically starts re-transition, and at the same time notifies the state change Therefore, the load applied to the transition process by the application or the state management module can be reduced. These elements have the effect of speeding up the processing.

  Further, when the system is activated, each application calls “ID assigning means” to acquire a unique ID. When the system activation process ends, the “application mode transition control means” determines the activation mode using an arbitrary method. The information acquired at this time is written in the most base part of the “system state management stack”, holds the current application mode, and makes it clear that the system state is “idle state”. When a common event (for example, key operation) for the “application” in the “idle state” occurs, the external handler issues a corresponding event to the management system using the “common API provided by the application management system”. The “event dispatcher” that received the message can directly notify the “application” using the event notification method held in the “system state management stack”. In addition, when a module that manages a certain system state detects a corresponding state transition factor (for example, when a module that manages an “error state” detects an error occurrence), “system state transition control means” Can be notified of a state transition request event.

  In addition, the “system state transition control unit” that receives the event determines the transition condition using an arbitrary method defined in advance, and performs the state transition process when the transition condition is satisfied, thereby performing the “system state management module”. And push the “system state management stack” to add “corresponding system state” on top of the current state. In the newly added “system state”, the event notification method defined by the “system state management module for managing the corresponding system state” is written. Therefore, the common event in the “corresponding system state” is directly notified to the “corresponding system state management module” on the same principle as described above, without any special control by the “application”. .

  Requests that do not satisfy the transition condition are queued by the “transition request event queuing step” and can be re-transitioned at an appropriate timing. The operation of restoring the state can be performed completely in a target manner only by changing the above-described push processing to the “state management stack” to the pop processing.

  An “application” that has received an external event that requires mode transition can send an application mode transition request event to “application mode transition control means” at an arbitrary timing. When the “application mode transition control means” receives the event, it refers to the information of the request source and the information of the “system state management stack” and performs the mode transition processing when the transition condition is satisfied, and the “system state management stack” The mode can be switched by writing new application information in the most basic part of "."

  Requests that do not satisfy the transition condition are queued by the “transition request event queuing step” and can be re-transitioned at an appropriate timing.

  As described above, the “application” can share the event handling using the common I / F determined by the “application management system”, and the I / F for sending the event to the application is also common. Therefore, the extensibility of the module can be improved.

  The “application mode transition control means” performs mode transition control based on the data sent by the transition request source, and the “system state transition control means” performs system state transition control by a predefined method. Since the current information is centrally managed by the “state management stack” by writing the management information to the “state management stack”, the event notification method is uniquely determined in any mode / state combination.

  Furthermore, the “system state management module” and the “system state transition control means” cooperate with the above-described method to perform system state transition and control in that state. It becomes possible to specialize in.

Example 1
A first embodiment of the present invention will be described. (This embodiment assumes that the present invention is applied to a multi-function printer, but it goes without saying that it can be applied to any apparatus having a similar system configuration.) First, this embodiment A configuration in the example will be described with reference to FIG. In the figure, reference numeral 100 denotes an application management system. An application mode transition control unit 101 receives an application mode transition request event generated from a specific process and controls the mode transition. Reference numeral 102 denotes a transition request event queue for storing a request event history when a transition condition is not satisfied in the transition process by the application mode transition control means (101) or the system state transition control means (103). It is. Reference numeral 103 denotes a system state transition control unit which receives a system state transition request event generated from a specific process and controls the state transition. Reference numeral 105 denotes a system state management stack, in which the current state is pushed or popped by the mode transition control means (101) or the state transition control means (103). An event dispatcher 113 notifies the common event to the application or the state management module. Reference numeral 114 denotes an ID assigning unit that provides a function of assigning a unique ID to a module to be controlled. Next, the operation of this embodiment will be described in detail.

  First, processing at the time of system startup will be described with reference to FIG. This figure shows the processing flow at the time of system startup. When the system is activated, after the OS resources and the like are initialized, first, the ID assigning means (114) is initialized in S2001. Subsequently, each application and the system state management module are activated, and ID assignment processing is performed in a loop of S2002 to S2004. The ID allocation in S2003 is a process in which each module calls an I / F provided by the ID assigning means (114) to acquire a unique ID. (Hereinafter, the ID given to the application is referred to as an application ID, and the ID given to the system state management module is called a system ID in the form of stationery.) Each module that has acquired the ID remembers its own ID. Keep it. When ID assignment to all applications and system state management modules is completed, each module acquires IDs of other modules necessary for control using functions such as inter-task communication. In step S2005, the application management system 100 is initialized, and in step S2006, information on the built-in application is set in the system state management stack (105). (As will be described later, this application is an application that is temporarily activated only until the system is in the middle of state transition and a valid mode is determined.) Thereafter, the application management system 100 performs the task. By using means such as delay, the execution right is handed over to the application, and during that time, a system-predetermined “default mode application” and any application issues a mode transition request event if transition factors are in place To do. The application management system 100 that has recovered the execution right activates the mode transition sequence in S2007, starts up the application at the time of initialization, and ends the process. (The mode transition will be described later.) Here, the method in which the ID assigning means (114) dynamically assigns an ID to each control target module has been described. Also good. In other words, a unique ID is statically assigned in advance using a macro or the like to the operation mode and system state extracted at the time of system design, so that the dynamic ID assignment process described here is omitted. It is also possible to do. This is the end of the description of the startup process.

Next, the application mode transition control process will be described with reference to FIG. (The description here will be discussed as a transition from application A to application B. Assume that the state before the transition is as shown in FIG. 21A.) FIG. Represents a flow. The processing in S501 to S502 represents processing by an external event handler. The processing in S503 to S505 represents processing by the process that is the mode transition request source. (The process that is the mode transition event request source is not necessarily the application itself, but for the sake of simplicity, it is assumed that the application B itself is the request source.) The processing in S506 to S520 is performed by the application management system. 100 represents processing. Further, the processing in S523 to S524 is not uniquely defined in context, and belongs to either the context of application A or the context of application management system 100 depending on the system. Similarly, the processing of S521 to S522 belongs to either the context of the application B or the context of the application management system 100. If the event handler detects an activation factor of the application B (S501), the event is transmitted to the application B using an arbitrary method. (S502) (The event handler and the activation factor can take any configuration depending on the system. For example, if the application B controls the direct printing function from the digital camera, the event handler It is possible to monitor an interface such as USB and kick the application B with the camera connection event as the activation factor.) The application B that has been waiting for the event receives a transition factor detection event from the handler in S503. In subsequent S504, a mode transition request event is generated through the interface (API) provided by the application transition control means (101). This interface includes (1) transition event request source, (2) type of transition event, (3) length of additional information, (4) pointer 111 to additional information, (5) priority 181 and (6) event The notification unit 182 is set and called by the application. Here, (3) and (4) are data depending on the caller and the event type. (The reason why the type explicitly defined as the additional data is not used is to eliminate the system-dependent portion as much as possible and to ensure the versatility of the application management system 100.) Also, (6) notifies the event. As a method for doing this, the function type is defined, and an event type and a pointer 84 to additional data are given as arguments. In the API, a memory area corresponding to the length of the additional information is secured, the contents of (4) are copied, and then a packet as shown in FIG. 18 is generated and sent to the application management system 100. In response to the occurrence of the mode transition event from the application B (ID = 2), the application management system 100 that is in the event waiting state in S506 enters the transition sequence. When the transition sequence is activated, it is first determined in S507 whether or not mode transition is possible. The mode transition enabling condition is determined by AND of the following three conditions.
1. The system state is idle. (The stack pointer points to the bottom.)
2. The internal state is not transitioning.
3. The priority of the mode at the transition destination is higher than the current priority.

  In order to acquire the information for the determination, the system state 34, the current priority 33, and the event notification method 35 (in this case, “in this case”) are transmitted from the state management stack 211 pointed to by the stack pointer 213 shown in FIG. FUNC_A ″) is read out. At the same time, the packet acquired in S506 is accessed, and the priority 33 and event notification method 35 (here, “FUNC_B”) of the transition destination mode are read. Using these pieces of information, it is determined whether the above conditions 1 and 3 are satisfied, and at the same time, it is determined whether the internal state that is internal information of the application management system 100 satisfies 2. The transition sequence continues when all conditions are met. (If the condition is not satisfied, a request event queuing process is performed in S509, which will be described later.) In S508, the internal state is set to the mode transition. In S511, after popping the state management stack 211, information on the built-in application is pushed. (A built-in application is a special application assigned with ID = 0, and is designed to perform provisional mode control immediately after activation or when the application management system 100 is in a transition processing state. The event notification method 35 (FUNC_SYS) defined by the time application accepts only a start request, a stop request, and a state transition notification, and all other common events fail, so a common event that occurs in the start application mode Are all sent to the system hook and do not respond to simple UI events, etc. In this connection, the event dispatch mechanism in the idle state will be described later.) Subsequently, in S512 and S513, in S507 Read it out Les event notification method 35 (FUNC_A, FUNC_B) a stop request to the application A with, and the application B sends an activation request, respectively. (At this time, additional information of the packet received in S506 is also sent together.) After performing these notification processes, the application management system 100 enters an event waiting state in S514. On the other hand, the application A that has received the stop request performs a process necessary for the stop in S523. (There are various processing contents depending on the system. For example, processing for switching the internal state or releasing unnecessary resources related to the display system, etc. can be considered.) Processing in S523 When the process is finished, in step S524, the application management system 100 is notified that the stop process is finished. (Notification is performed using an interface such as an API prepared by the application management system 100.) Similarly, the application B performs activation processing (reservation of display resources, initial display, etc.) in S521, and then activation processing in S522. An end notification is sent to the application management system 100. (As described above, the context in which these two processes are performed may be the application side or the application management system side. That is, if the processes of S523 and S524 can be completed in FUNC_A called in S512, the execution is performed. The context is on the management system side, and if only event notification is performed here, the execution context is on the application side, which form depends on the processing load etc. The important thing is to always synchronize with the process end notification.) When the application management system 100 that has been in the event waiting state in S514 confirms that both the stop end notification and the start end notification have been prepared, the mode transition is performed. Continue the sequence and proceed to S515. The arm state management stack 105 writes the management information of the application B, and clears the internal state was being further mode transition. Further, the transition request event queue 102 is examined in S516, and if there is a pending event, the top element of the list is extracted in S518. The event type 83 of the extracted element is checked in S519. If the event is a state transition request, the process branches to S1007 to start the state transition control sequence. If it is a mode transition request, the process returns to S507 again. A new mode transition sequence is entered. If the queue is empty, the process ends there. (Waiting for an event in S517) When the mode transition process ends, the state in the application management system 100 is as shown in FIG. 21B, and is in a mode managed by the application B (note that data in the state management stack 211) The structure is also shown in FIG. 21C).

  Next, the mode transition request event hold processing performed in S509 will be described with reference to FIG. When the process is started, the mode transition control means (101) checks the transition request event queue (102) in S601 to check whether the list is not empty. When the list is empty, a list area is secured in S602, and necessary information is copied to the list element and connected to the head of the list. If the list is not empty, a list search process is performed in S603. The search processing is performed in the order of (1) search for an element equal to the ID of the target event, and (2) search for an element lower than the priority of the target event (the smaller the numerical value, the higher the priority). If there is a hit, only the element replacement process is performed in S604. If no hit is found in (1), a new list element in which the content of the target event is copied immediately before the element searched in (2). insert. (S605) (In the search process of (2), if the priority of all elements in the list is equal to or higher than the priority of the target event, it is connected to the end of the list.) Finally, in S606 The event notification method 35 of the target event is used to notify that the event has been suspended and the suspension factor (whether it is due to priority or system state). The structure of the queuing list used here is, for example, as shown in FIG. FIG. 6A shows the data structure of the list element, the previous 81 / next 82 are pointers to the elements connected before and after the ID, the ID 33, the priority 33, and the event notification method 35 are all mode transitions. This is information about the request issuer. The event type 83 is a transition request event that causes a transition sequence activation. The list is held as a one-dimensional linked list in order of priority as shown in FIG. (The list structure shown here is a general-purpose list structure with priorities that is generally used. Here, the structure is merely illustrated, and the scope of the present invention is not limited to this structure. The above is the sequence of the mode transition request event hold processing, but the held event is always hooked at the timing of state transition, as will be described later. If waiting for the hold to be released, the mode transition condition may be lost (for example, the digital camera once connected is removed), or there is no need to hold it in the first place due to system specifications. Therefore, the mode transition control means (101) also includes an interface for canceling the pending transition request event. The process called through this interface releases the hold event by the sequence flow shown in FIG. This is the end of the description of the mode transition request event hold processing.

  Next, the system state transition control process will be described with reference to FIG. This figure shows the flow of system state transition control processing. In the figure, the processing of S1001 to S1002 represents processing by an external event handler. The processing from S1003 to S1005 represents processing at the transition request source. Further, the processing of S1006 to S1018 represents processing in the application management system 100. If the event handler detects a state transition factor (S1001), the event is notified to the module that is the state transition request source using an arbitrary method. The process from when the state transition request source calls the API provided by the application management system 100 to notify the state transition request event is almost the same as that performed in S503 to S506 in the mode transition control. The explanation is omitted. As a result, a packet of the type shown in FIG. 18 is sent to the application management system 100, and the occurrence of the state transition request event is recognized.

Here, the definition of the state transition request event will be described. The packet event type 83 stores either (1) an up stack event or (2) a down stack event. Two event definitions are given below.
(1) Up stack event A new state is stacked on the state management stack.
(2) Down stack event The state that has already entered the state management stack 211 is released.

  Returning to FIG. 10 again, the description of the sequence will be continued.

In step S1006, the application management system 100 that has received the event calls the state transition control unit to start the state transition sequence. In the sequence, first, the contents of the packet received in S1007 are analyzed, and the system ID of the transition destination and the event notification method 35 are acquired from the packet. If the event notification method 35 acquired here is NULL, this request is regarded as invalid, the event is discarded, and the process ends. When the event notification method 35 is valid, it is determined whether or not the transition enable condition is satisfied. In order for the transition to be permitted, the following conditions must be satisfied according to the event type 83.
(1) Up stack event 1. The internal state is not in transition processing and The current state management module permits the transition.
(2) At a down stack event The internal state is not in transition processing.

  In the case of an up-stack event, a state transition determination request event is sent together with the system ID of the transition destination to the event notification method 35 of the current state management module in order to evaluate the condition of 2. The application management system 100 evaluates two conditions according to the return value of this function. If it is determined that the transition is possible, the transition sequence is continued and the process proceeds to S1008. (If the transition is not possible, the state transition request event hold processing is performed in S1009, but this processing is the same as the processing in FIG. 6. However, unlike the mode transition request, all the state transition requests have priority. (Because it is treated as an event of degree 0 (maximum priority), it is always connected before the mode transition request. Also, the order of the state transition requests is a FIFO type.) In S1008, the internal state of the application management system 100 is changed to the state. Set during transition processing. In the subsequent S1011, the system state management stack 105 is set to that of the built-in application. (This process is the same as S511.) Next, in S1012, branching is performed according to the event type, and the up stack process (S1014) or the down stack process (S1013) is started. When these processes are completed, a process corresponding to the queuing list is performed in S1015 to S1018 (the same as the process in S516 to S519).

  Next, the up stack process in S1014 will be described with reference to FIG. First, in S1201, an activation request event is issued to the transition destination, and then an event wait state is entered. (S1204) When the transition destination returns an activation end notification, the sequence is continued, and the state management stack 211 is operated in S1205. In this process, the stack is first popped to cancel the built-in app state, and then the transition destination state is pushed onto the stack. Finally, in step S1207, a state transition notification event is issued to all modules on the current state management stack 211. At this time, data having the structure shown in FIG. 14 is sent to each module together with the event. In the same figure, ID 141 in the previous state and ID 142 in the current state are System IDs (application IDs in the case of an application) representing the state at the top of the stack before and after the transition, respectively, and event type 83 is the starting point of the transition. It is a transition request event (up stack request, down stack request, mode transition request), and the additional information is sent from the transition request source when the request event is issued. Each module can perform the required operation by analyzing these data sent in synchronization with the notification event (for example, after the state transition request event is issued once and the queue is deleted) Thus, the module that has been waiting for the resending timing of the transition request can make a state transition request if it can be determined that the transition is possible by analyzing the data).

  Next, the down stack process will be described with reference to FIG. First, in step S1301, the state management stack 211 is searched from top to bottom, and information equal to the request source ID is extracted. (The stack after removal is packed) Next, after a stop request event is thrown to the target module in S1302, an event wait state is entered in S1305. When the stop end notification is received from the module that has received the stop request event, the sequence is continued and the state management stack 211 is operated in S1306 to release the built-in app state. Thereafter, a state transition notification event issuing process (S1308) is performed to end the sequence (these processes are the same as those in S1207).

  Here is a brief description of state nesting. In a carefully designed system, multiple occurrences of the same state on the state management stack 211 are rare. (Conversely, the system should be designed in that way.) However, in some cases, it may be unavoidable that nesting of states occurs. For example, after an error occurs and the error state 151 is entered, the error state 151 is entered to enter the A state 152 for error cancellation, where an error occurs again and the module managing the state A performs no corresponding processing. In such a case, it is conceivable that a stacked state as shown in FIG. As described above, in the down stack processing, the stack search in S1301 is performed from the top to the bottom, and the sequence can be canceled even if the target is not at the highest level. Even if the error and the second error that occurred are canceled at the same time, and the error state management module does not perform complicated sequence management and only throws the down stack event twice in succession, It is possible to match.

Next, an event dispatch sequence in this system will be described with reference to FIG. This sequence is activated when the generated event is other than the transition request event described above. The operation in which the external handler that detected the event occurrence factor in S1601 notifies the event using the API provided by the application management system 100 in S1602 is exactly the same as the processing described in FIG. 5 or FIG. (However, in this case, the only valid packet data shown in FIG. 18 is the event type 83 and a pointer to the additional information.) The application management system 100 that has received the event notification in S1603 receives the event dispatch means ( 113) to invoke the dispatch sequence. When the sequence is activated, an event is notified in step S1604 using the module event notification method 35 stored in the position pointed to by the stack pointer of the system state management stack 105. In S1605, the return value of the called callback is seen, and if the process is successful, the process branches to S1606 to end the sequence. If the callback function returns a processing failure, the system dispatch of S1607 is performed. The system dispatcher is implemented so as to mainly process events from the system by using a predefined (or dynamically registered) routine. (For example, when a power key is pressed during operation, it is common to perform an operation to turn off the system in a unified manner. It is a system dispatcher that processes such an event.)
Above, description of all the control sequences in a present Example is completed.

(Example 2)
A second embodiment of the present invention will be described. (This embodiment assumes that the present invention is applied to a multi-function printer, but it goes without saying that it can be applied to any apparatus having a similar system configuration.) First, this embodiment A configuration in the example will be described with reference to FIG. (In the figure, components having the same functions as the components in FIG. 1, which is the configuration diagram of the first embodiment, are given the same reference numerals and will not be described).
In the figure, reference numeral 1700 denotes an application management system. An application management table 1706 includes an application registration table (1707) and a system state management module registration table (1708 to 1711) as its contents. An application registration unit 1712 provides an interface for the application to register application management information in the application management table (1706) or to delete the application management information from the application management table (1706). An event dispatcher 113 notifies the common event to the application or the state management module. Reference numeral 1714 denotes initialization synchronization means, which provides a synchronization function necessary for an application to perform a registration operation when the system is activated. Next, the operation of this embodiment will be described in detail.

  First, application registration / deletion processing will be described.

  First, application registration processing will be described with reference to FIG. This figure shows the flow of application registration processing performed at the time of system startup. When the system is activated, the initialization synchronization means (1714) is first initialized after the OS resources and the like are initialized, then each application task is activated, and each application is initialized and synchronized in the loop of S201 to S203. Get the flags you need for. This process is a process in which each application calls the initialization synchronization means (1714) to acquire a unique flag. At this time, the initialization synchronization means (1714) remembers all the flags given by itself. The application that has acquired the flag enters a waiting state by going to get a common semaphore whose initial value is 0, for example. When all the applications acquire the flag and enter a waiting state, the application management system 1700 is activated in S204 and initializes itself. In this initialization, initialization processing is added to dynamic resources such as an application management table (1706) and a system state management stack (105). When the initialization of the application management system (1700) is finished, the application management system (1700) calls the initialization synchronization means (1714) to notify the end of the initialization and enters a waiting state. The initialization synchronization means (1714), for example, releases the above-described semaphore to bring the first application in the queue into an operating state. Each application that has been in a waiting state after acquiring the initialization synchronization flag performs application registration in a loop of S205 to S208 in synchronization with this event. The application registration process performed in S206 is a series of procedures for recording its own application management information in the application management table 1706 using the application registration means (1712). The application management information includes the information shown in FIG. 3, and designates its own priority 33, event notification method 35, and event notification method 35 in a predefined system state 34 as shown. (In the system of this embodiment, “Print state”, “Error state”, and “InkChange state” are defined as the system state 34. Of course, these definitions are determined depending on the system. It is assumed that the management information shown in FIG. 3A is sent from the application (A) to the application registration means (1712). The registration means (1712) assigns a unique application ID = 1 to the application (A). Next, the sent priority 33 and the event notification method 35 are written in the item “ID = 1” in the application registration table (1707). Further, the event notification method 35 in each state sent is written in the system state management module registration table (1708) linked to ID = 1. At this time, if the event notification method 35 is designated as “Default” as illustrated in the third line (or the fourth line) of FIG. 3A, the default method prepared in advance by the system is used. Write to the state management module registration table (1708). Further, as illustrated in FIG. 3B, for a system state with no registration designation, “NULL” is written in the corresponding element of the system state management module registration table (1708), and an invalid system in the application mode is written. Specify state. When the writing process to the application management table 1706 is completed, the application registration unit 1712 returns the allocated application ID to the calling application. The application that has acquired its own ID stores the ID, and notifies the initialization synchronization means (1714) of its own initialization synchronization flag in S207 to notify that the registration process has ended. The initialization synchronization means (1714) to which the initialization synchronization flag is returned gives the registration right to the next application by, for example, releasing the above-described semaphore again after clearing the flag. By repeating the above operation until all the initialization synchronization flags are cleared, the loop of S205 to S208 is completed. (Note that the substance of the application that performs mode control in each mode (that is, having a different application ID) does not necessarily have to be different. If the mode is divided, the prospect is better, but the task is divided to consume resources. If there are two adjacent modes whose value cannot be found, it is also a suggestion that the same module controls the two modes.) Example of application management table (1706) generated by application registration processing Is shown in FIG. An application assigned ID = 1 has a priority = 128, and the event notification method 35 is given by “FUNC_A”. The “Print state”, “Error state”, and “InkChange state” can all be handled, and an event notification method 35 in the “Print state” defines a unique method. Similarly, an application having ID = 2 has a priority = 64, and the event notification method 35 is given by “FUNC_B”. Further, the “print state” is not taken out of the system states. The application with ID = 0 has a priority of 255, and all system states are invalid. (As will be described later, this application is a “built-in application” that is temporarily activated until the system is in the middle of state transition and a valid mode is determined.) System state management module registration table 42 "System ID" is described as a state name, which is used for identifying a pre-defined system state by an ID number. However, since this is the same as the first embodiment, the description is omitted).

  Next, application deletion processing will be described. The application requesting deletion calls an interface provided by the application registration unit 1712 with its own ID as an argument. The application registration means first checks the top base of the state management stack 211, and returns failure if the mode having the ID to be deleted is active. If not, the information in the corresponding item in the application registration table 1707 and the system state management module registration table 42 associated therewith are deleted, and the process ends.

  This completes the description of the operation related to the application registration / deletion processing. However, the synchronization management process by the initialization synchronization means described here has a possibility of changing depending on the type of OS used, and the method described above. It is not limited to. In other words, it is important that the application registration process is performed after the application management system 1700 is initialized, and whatever the means for realizing it is within the scope of the present invention. is there. (For example, a scene where dynamic registration processing is performed after the system initialization processing can be assumed, but it is needless to say that it can be easily realized by the above-mentioned method.) Conversely, application registration processing is system initialization. It is practically impossible to do before because these resources must be controlled during a period when the application management table 1706 and the state management stack 211 are indefinite.

  Next, the application mode transition control process will be described with reference to FIG. In the figure, the same reference numerals are given to the portions showing the same processing contents as in FIG. 5, and the description will be omitted. Also in this embodiment, the discussion will be made on the assumption that the application A changes to the application B. (The state before the transition is as shown in FIG. 7A.) After the external event handler receives the transition factor and sends the external event to the process that is the transition request source, in step S2204, the application transition control means (101 The mode transition request event is generated through the interface (API) provided by the (). Unlike the first embodiment, this API specification uses (1) transition event request source, (2) type of transition event, (3) length of additional information, and (4) pointer to additional information as arguments. . The structure of a packet generated by this API call is shown in FIG. 11, and the application management system 1700 that has received this packet activates a mode transition sequence in the same manner as in the first embodiment. The logic for determining whether or not to allow transition in S2207 is exactly the same as in the first embodiment. However, the information of the transition destination mode is not obtained from the packet, but the priority 33 of the transition destination mode and the event notification method 35 (here, “FUNC_B”) stored in ID = 2 by accessing the application registration table 1707 Is read out. After that, the same processing as in the first embodiment is performed until S2211, and in S2211, processing for replacing the status management module table with that of the same application is added at the same time that the information of the built-in app is set in the system status management stack 105. . Similarly, in S2215, in addition to the stack operation, the state management module table replacement process is performed. Since the subsequent processing is exactly the same as in the first embodiment, description thereof is omitted. When the mode transition process ends, the state of the application management system 1700 is as shown in FIG. 7B, and the application mode is switched.

  Next, the system state transition control process will be described with reference to FIG. In the figure, the same reference numerals are given to the portions showing the same processing contents as those in FIG. 10, and the description will be omitted. In the state transition request event sending process in S2304, the API specification provided by the application management system 1700 is different from the packet data configuration that the API sweeps out, as in the mode transition control. The processing in S2307 only changes the data collection destination from the packet to the system state management module registration table. In the processing in S2311, in addition to the stack operation, only the change processing of the system state management module registration table occurs. All subsequent processing is the same as in the first embodiment.

  Since the event dispatch sequence is exactly the same as in the first embodiment, description thereof is omitted.

  Above, description of all the control sequences in a present Example is completed. Also in this embodiment, it is possible to perform the start request process and the stop request process in the context of the application management system 1700. Also, as an item specific to this embodiment, having an application management table makes it possible to provide a unified interface for other processes to retrieve various information managed there as needed. This has the effect of increasing the flexibility of control.

  Another object of the present invention is to supply a storage medium (or recording medium) on which a program code of software that realizes the functions of the above-described embodiments is recorded to a system or apparatus, and the computer (or CPU or CPU) of the system or apparatus Needless to say, this can also be achieved by the MPU) reading and executing the program code stored in the storage medium.

  In this case, the program code itself read from the storage medium realizes the functions of the above-described embodiments, and the storage medium storing the program code constitutes the present invention.

  Further, by executing the program code read by the computer, not only the functions of the above-described embodiments are realized, but also an operating system (OS) or the like running on the computer based on an instruction of the program code. It goes without saying that a case where the function of the above-described embodiment is realized by performing part or all of the actual processing and the processing is included.

  Further, after the program code read from the storage medium is written in a memory provided in a function expansion card inserted into the computer or a function expansion unit connected to the computer, the function expansion is performed based on the instruction of the program code. It goes without saying that a case where the function of the above-described embodiment is realized by performing part or all of the actual processing such as the CPU provided in the card or the function expansion unit and performing the processing.

  The above-described program only needs to be able to realize the functions of the above-described embodiments by a computer, and the form includes forms such as object code, a program executed by an interpreter, and script data supplied to the OS. But you can.

  As a recording medium for supplying the program, for example, RAM, NV-RAM, floppy (registered trademark) disk, optical disk, magneto-optical disk, CD-ROM, MO, CD-R, CD-RW, DVD (DVD-ROM, DVD-RAM, DVD-RW, DVD + RW), magnetic tape, non-volatile memory card, other ROM, etc. may be used as long as they can store the above programs. Alternatively, the program is supplied by downloading from another computer or database (not shown) connected to the Internet, a commercial network, a local area network, or the like.

The figure showing the structure of the 1st Example of this invention The flowchart showing the application registration process in the second embodiment of the present invention. The figure showing the application registration information in 2nd Example of this invention The figure showing the structure of the application management table in 2nd Example of this invention. The flowchart showing the application mode transition control sequence in the first embodiment of the present invention. Flowchart showing transition request event queuing processing in the present invention The figure for demonstrating the application mode transition in 2nd Example of this invention The figure showing the structure of the transition request event queuing list in this invention Flowchart showing transition request event queue element deletion processing in the present invention The flowchart showing the system state transition sequence in the first embodiment of the present invention. The figure showing the data structure of the event packet which an application management system receives in 2nd Example of this invention The flowchart showing the up-stack transition process in the present invention The flowchart showing the down stack transition process in this invention. The figure which shows the data structure of the event which a system sends to the process on a stack after a state transition completion in this invention The figure which shows an example when the system state is nested in this invention The flowchart showing the event dispatch sequence in this invention The figure showing the structure of 2nd Example of this invention. The figure showing the data structure of the event packet which an application management system receives in 1st Example of this invention The flowchart showing ID allocation processing in the first embodiment of the present invention. The flowchart showing the process at the time of starting in the first embodiment of the present invention. The figure for demonstrating the application mode transition in 1st Example of this invention The flowchart showing the application mode transition control sequence in the second embodiment of the present invention. The flowchart showing the system state transition sequence in the second embodiment of the present invention.

Explanation of symbols

DESCRIPTION OF SYMBOLS 100 Application management system 101 Application mode transition control means 102 Transition request event queue 103 System state transition control means 105 System state management stack 113 Event dispatch means 114 ID assignment means 1700 Application management system 1706 Application management table 1707 Application registration table 1708 System state management Module registration table 1709 System state management module registration table 1710 System state management module registration table 1711 System state management module registration table 1712 Application registration means 1714 Initialization synchronization means 31 Information to application registration table 32 Information to system state management module registration table Distribution 33 priority 34 system state 35 event notification method 41 application registration table 42 the system state management module registration table 43 ID
45 states 81 previous
82 next
83 Event type 84 Pointer to additional data 111 Pointer to additional information 141 Previous state ID
142 ID of current state
151 Error state 152 A state 153 Error state 154 Base state 181 Priority 182 Event notification means 211 State management stack 212 Application 213 Stack pointer

Claims (21)

An application management method in a system having a plurality of application modes or a multi-function printer system,
A system state management stack, an event dispatch step for event dispatch,
A transition control step for performing application mode transition control, a transition control step for performing system state transition control, an event queuing step for performing transition request event queuing, an ID providing step for performing ID assignment,
An application management method comprising: An application management method in a system having a plurality of application modes or a multi-function printer system,
Registration / deletion step for application registration / deletion, application management table, system state management stack, event dispatch step for event dispatch,
A transition control step for performing application mode transition control, a transition control step for performing system state transition control, an event queuing step for performing transition request event queuing, an initialization synchronization step for performing initialization synchronization,
An application management method comprising:   3. The system state management stack according to claim 1, wherein the system state management stack holds an ID, a priority order, and an event notification method related to a target state, and has a stack pointer indicating a current state. Application management method. The event dispatch step for performing the event dispatch is to send the sent event,
Sending to the corresponding module using the event notification method corresponding to the state at the top of the system state management stack;
The application management method according to claim 1, further comprising a calling step of calling a predefined default event processing method when the event notification method fails.   The transition control step for performing the application mode transition control is characterized in that, when a transition request event is queued, the event notification method of the transition request source is used to notify that the request event is suspended. The application management method according to claim 1 or 2.   3. The application management method according to claim 1, wherein the event queuing step for performing the transition request event queuing holds the transition request events by switching in order of priority.   The transition control step for performing the system state transition control is characterized in that, when the state transition processing is performed, all event notification steps in the state management stack are notified that the state transition has been performed. The application management method according to claim 1 or 2.   The transition control step for performing the system state transition control is characterized in that, when a state transition request event is queued, the event notification method of the transition request source is used to notify that the request event is suspended. The application management method according to claim 1 or 2. The transition control step for performing the application mode transition control includes:
A read step for reading the current state (ID), event notification method and priority at the top of the system state management stack;
A step of taking out the ID of the transition destination mode, the event notification method, and the priority included in the sent application mode transition request event;
A first evaluation step for evaluating that the current state is equal to a specific state;
A second evaluation step for comparing the priority of the current state with the priority of the transition destination mode and evaluating that the priority of the transition destination mode is higher than the priority of the current state;
And a third evaluation step for evaluating that the internal state of the application management system is not transitioning,
When the evaluation results of the first evaluation step, the second evaluation step, and the third evaluation step are all true, a mode transition process is performed, and the first evaluation step, the second evaluation step, and the third evaluation step are performed. When at least one of the evaluation results of the evaluation step is false, the application mode transition request event is queued by using an event queuing step for performing the transition request event queuing without performing the mode transition. The application management method according to claim 1. The transition control step for performing the application mode transition control includes:
A read step of reading a current state (ID), an event notification method and a priority at the top of the system state management stack;
An extraction step of retrieving the ID of the transition destination mode included in the sent application mode transition request event;
A reading step of reading a priority order and an event notification method in the application management table stored in association with the transition destination mode ID;
A fourth evaluation step for evaluating that the current state is equal to a specific state;
A fifth evaluation step for comparing the priority of the current state with the priority of the transition destination mode and evaluating that the priority of the transition destination mode is higher than the priority of the current state;
A sixth evaluation step for evaluating that the internal state of the application management system is not transitioning;
When the evaluation results of the fourth evaluation step, the fifth evaluation step, and the sixth evaluation step are all true, a mode transition process is performed, and the fourth evaluation step, the fifth evaluation step, and the sixth evaluation step are performed. When at least one of the evaluation results of the evaluation step is false, the application mode transition request event is queued using an event queuing step for performing the transition request event queuing without performing mode transition. The application management method according to claim 2. In the transition control step for performing the system state transition control, when the sent state transition request event is an up stack event,
A reading step of reading a current state (ID) at the top of the system state management stack and an event notification method;
An extraction step of retrieving the ID and event notification method of the transition destination mode included in the sent state transition request event;
A seventh evaluation step of evaluating a transition possible condition using the event notification method in the current state;
An eighth evaluation step for evaluating that the internal state of the application management system is not transitioning;
When the evaluation results of the seventh evaluation step and the eighth evaluation step are all true, state transition processing is performed, and at least one of the evaluation results of the seventh evaluation step and the eighth evaluation step is false. 2. The application management method according to claim 1, wherein the state transition request event is queued by using an event queuing step for performing the transition request event queuing without performing a state transition. In the transition control step for performing the system state transition control, when the sent state transition request event is an up stack event,
A reading step of reading a current state (ID) at the top of the system state management stack and an event notification method;
An extraction step of extracting the ID of the transition destination mode included in the sent state transition request event;
A reading step of reading an event notification method in the application management table stored in association with the transition destination mode ID;
A ninth evaluation step of evaluating a transition possible condition using the event notification method in the current state;
A tenth evaluation step for evaluating that the internal state of the application management system is not transitioning;
When the evaluation results of the ninth evaluation step and the tenth evaluation step are all true, state transition processing is performed, and at least one of the evaluation results of the ninth evaluation step and the tenth evaluation step is false. 3. The application management method according to claim 2, wherein the state transition request event is queued by using an event queuing step for performing the transition request event queuing without performing a state transition. In the transition control step for performing the system state transition control, when the sent state transition request event is a down stack event,
A step of taking out the ID of the cancellation target mode included in the sent state transition request event;
Retrieving a state ID from the top of the system state management stack and retrieving stack information at a position that first matches the ID of the release target mode;
An eleventh evaluation step for evaluating that the internal state of the application management system is not transitioning;
When the evaluation result of the eleventh evaluation step is true, state transition processing is performed. When the evaluation result is false, the state is obtained using an event queuing step of performing the transition request event queuing without performing state transition. The application management method according to claim 1, wherein the transition request event is queued.   The transition control step for performing the system state transition control is performed by a stacking step of stacking a new state on the stack with respect to the current state, and an extracting step of extracting the current state from the stack. The application management method according to claim 1 or 2.   The application management method according to claim 2, wherein the application management table separately manages an application registration table and a system state management module registration table.   3. The application management method according to claim 2, wherein the application management table has at least one system state management module registration table associated with each management unit of the application registration table.   The registration / deletion step for registering / deleting the application receives a mode transition condition and an event notification method from an application to be registered, and an ID number assigning step for assigning a unique ID number to the target application; 3. A registration step of registering a mode transition condition and an event notification method in the application management table in association with the ID number, and a function of notifying the ID number to an application to be registered. Application management method as described.   The event notification method received from the application by the registration / deletion step of registering / deleting the application is characterized in that the application itself is configured to be a notification destination and an arbitrary number of other processes are notification destinations. The application management method according to claim 2.   The initialization synchronization step of performing the initialization synchronization includes a control step of performing control so that the resource initialization of the application management system is performed prior to the application registration process at the time of system startup. Application management method. A control program for realizing an application management method in a system having a plurality of application modes or a multi-function printer system,
A system state management stack, an event dispatch step for event dispatch,
A transition control step for performing application mode transition control, a transition control step for performing system state transition control, an event queuing step for performing transition request event queuing, an ID providing step for performing ID assignment,
An application management method control program comprising: A control program for realizing an application management method in a system having a plurality of application modes or a multi-function printer system,
Registration / deletion step for application registration / deletion, application management table, system state management stack, event dispatch step for event dispatch,
A transition control step for performing application mode transition control, a transition control step for performing system state transition control, an event queuing step for performing transition request event queuing, an initialization synchronization step for performing initialization synchronization,
An application management method control program comprising:

Images