JPH09185528A - Method and device for inspecting software - Google Patents

Abstract

PROBLEM TO BE SOLVED: To minutely inspect the operation of multi-task software for detecting the error of inter-task interface. SOLUTION: Multi-task software 1001 operating on hardware loading a low speed communication equipment is inspected by operating multi-task software 1001 on a real time basis and automatically detecting violence against interface specification between tasks, which is previously set, and incorporating an inspection method for inspecting multi-task software 1001 into a multi-task monitor 1005.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a software inspection method and an apparatus therefor, and more particularly, to a software inspection method and an apparatus therefor for performing real-time operation such as software when incorporated in hardware.

[0002]

2. Description of the Related Art Software inspection is usually performed using a program debugger. The program debugger can stop and restart the execution of the program at an arbitrary line of the program source, and can display and change the status of the program variables and flags when the execution is stopped. Therefore, the software developer interactively uses the program debugger to search for a bug in the software and repeats the work of fixing the bug to complete the software.

In a larger real-time system, a task division programming method based on a multitasking mechanism is generally used.
A tracer for inter-task events has been put into practical use, in which control transitions between tasks, message transmission / reception, and synchronization functions are accumulated in an external storage device. Therefore, in task division programming, the method of verifying the interface between tasks using the event tracer between tasks and verifying individual tasks using the program debugger is the most efficient software verification method at present. Is considered to be.

[0004]

However, the above-mentioned technique has the following problems.

In software for the purpose of controlling hardware, stopping the execution of a program may damage the hardware to be controlled, so it is not always possible to stop the execution of the program. For this reason, it is not possible to efficiently use the program debugger in software for such purposes.

Also in the development of multitask software, the intertask event tracer only reports / displays the event series, and from the trace result,
Judgment regarding the correctness of the operation sequence of multitasking software relies on humans. Normally, an inter-task event occurs in units of several ms to several tens of ms, so even if the software operation is short, a huge amount of trace results are generated, and it is usually impossible to judge its correctness. is there.

[0007] Therefore, for the defect phenomenon of the multitask software, the method of carefully examining the trace result including the occurrence of the phenomenon and searching for the direct cause of the defect seems to be most effective. The inspection device is not very capable of detecting software defects.

Further, since the tracer transfers a huge amount of trace data to the external storage device, the hardware on which the multitask software is mounted must have a high speed communication function, and otherwise, Tracers cannot be used in the development of multi-task software to be installed in hardware.

The present invention is intended to solve the above-mentioned problems, and provides a software inspection method and apparatus for detecting an error in an interface between tasks without inspecting the operation of multitask software in detail. The purpose is to provide.

[0010]

The present invention has the following configuration as one means for achieving the above object.

The software inspection method according to the present invention is
The multitask software is inspected by operating the multitask software in real time and detecting a violation of a preset interface specification between tasks.

The software inspection apparatus according to the present invention operates the multitask software in real time,
Operates on hardware equipped with a low-speed communication device by incorporating a software inspection method that inspects the multitask software by detecting a violation of preset interface specifications between tasks. It is characterized by performing the inspection of the multitasking software.

[0013]

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS A software inspection apparatus according to an embodiment of the present invention will be described in detail below with reference to the drawings.

[Functional Configuration] FIG. 1 is a functional block diagram showing an exemplary configuration of a software inspection apparatus according to an embodiment of the present invention.

In the figure, an event response table (hereinafter sometimes simply referred to as "table") 1002 is composed of an event response pair expressing the inter-task interface specification of the multitask software 1001 to be inspected. The multitask monitor 1005 realizes a multitask operation and has a verification function of the multitask software 1001 based on the inter-task interface specification of the table 1002.
The multitask monitor 1005 manages a task control block (TCB) 1006 that holds the task state and a resource 1007 that implements intertask communication and intertask synchronization functions.

By issuing a service request 1004 to the multitask monitor 1005, the multitask software 1001 can change the task state and access the resource. In addition, the multitask software 1001 calls the timer service 1003 in response to the periodic timer interrupt from the hardware timer, and provides the system clock to the multitask monitor 1005.

The multi-task monitor 1005 is a task interface resource specification of the multi-task software 1001 from the input / display device 1011 via the communication device 1008 at the time when the tasks and resources necessary for executing the multi-task software 1001 are generated. Event-representing event is read and saved in table 1002.

The multitask monitor 1005 is a service request
When an event such as a transmission / reception / reception request to a resource issued through 1004 matches the event part of the table 1002, the corresponding response (action) is monitored to be executed within a predetermined allowable time. If the response to the occurred event is not executed within the allowed time, the multitasking monitor 1005 reports an error to the input / display device 1011 via the communication device 1008.

[Multitask Software] FIG. 2 is a diagram showing typical multitask software.

In the figure, an interrupt handler 2001 processes an interrupt 2041 from the hardware, and a timer interrupt handler 20
02 handles the interrupt 2042 from the hardware timer. Further, 2011 to 2013 are tasks that realize unique processing.

The queue 2021 for realizing inter-task communication passes information from the interrupt handler 2001 to the task 2011, and similarly, the queue 2022 for realizing inter-task communication is used for passing information from the task 2012 to the task 2013. .

Bit 0 of the event flag 2031 for realizing the inter-task synchronization function is set by the task 2011 and is used for synchronization between the task 2012 and the task 2011. Bit 1 of event flab 2031 is set by task 2013,
Used to synchronize task 2011 and task 2013.

FIG. 3 is a sequence diagram showing a time series operation example of the multitask software shown in FIG. In addition,
In this sequence diagram, the task priority is 2011> 2
The order is 012> 2013, and it is assumed that the priority of the interrupt handler 2001 is higher than that of each task.

At the timing t0, tasks 2011, 2012, 20
13 is in a suspended state and interrupt 2041 at timing t1
Occurs and interrupt handler 2001 is started. The interrupt handler 2001 sends a transmission event to the queue 2021 at the timing t2.
Issue 2051. Further, at this time, the task 2011 is satisfied from the queue reception request 2052 requested at the timing t0 and transits from the suspended state to the execution waiting state.

At the timing t3, the interrupt handler 2001
Ends, the control is switched to the task 2011 in the executable state (execution state or execution waiting state).

At timing t4, the task 2011 issues the send event 2053 to the event flag 2031 and the task
In 2012, the reception event 2054 is received from the event flag 2031 and the state transitions to the execution waiting state.

At timing t5, the task 2011 issues a reception request 2058 to the event flag 2031 and transits to the suspended state. At this time, only task 2012 is ready to run, so at time t6, task 2012 is queued.
The send event 2055 to 2022 is issued, the task 2013 receives the receive event 2056 from the queue 2022, and the task 2013 transits from the suspended state to the execution waiting state.

At timing t7, the task 2012 issues a reception request 2054 to the event flag 2031 and transits to the suspended state. At this time, since the task 2013 is the only executable state, the task 2013 transitions to the execution state.

At timing t8, the task 2013 issues a transmission event 2057 to the event flag 2031 and transitions to the execution waiting state. Also, higher priority tasks 20
11 receives the reception event 2058 from the event flag 2031 and transits to the execution state.

At the timing t9, the task 2011 issues the reception request 2052 to the queue 2021 and enters the suspended state, and the task 2013 enters the execution state. Then, at the timing t10, the task 2013 issues a reception request 2056 to the queue 2022 and enters the suspended state, at which point all the tasks return to the initial state similar to the timing t0.

FIG. 4 is a diagram showing an inter-task interface protocol by an event-response expression, which is a protocol that the multi-task system shown in FIG. 2 must follow in order to operate according to the sequence diagram of FIG.

As shown in the figure, the queue 2021 must respond with a reception event 2052 if a transmission event 2051 occurs. Also, the queue 2022 must respond with a receive event 2056 if a send event 2055 occurs. Also, event flag 2031
Must respond to the send event 2053 with a receive event 2054 and the send event 2057 with a receive event 2058.

In task 2011, received event 2052
Indicates that a send event 2053 followed by a receive request event 2058 is triggered.
It is shown that a reception request event 2052 is triggered for 2058.

Further, in Task 2012, it is shown that the transmission event 2055 and the subsequent reception request event 2054 are triggered for the reception event 2054. Similarly, in Task 2013, for the reception event 2056, Send event 2057 followed by receive request event 20
56 has been shown to be triggered.

As long as all of the above protocols are satisfied, the multitasking software shown in FIG. 2 is the same as that shown in FIG. 3 except for which task among the tasks that can be executed at the time of task scheduling is executed first. The operation is guaranteed according to the sequence diagram shown in FIG.

In the following, the event-response representation for a more complex task-to-task interface will be verified.

[Complex task-to-task interface (type
1)] FIG. 5 is a diagram showing an example of a complicated inter-task interface, which is an inter-task interface in which a plurality of tasks transmits to one queue and further a plurality of tasks receives.

In the figure, a queue 5001 is for transferring data between tasks, and tasks 5011 and 5012 are tasks for transmitting data to the queue 5001.
21 and 5022 are tasks for receiving data from the queue 5001.

When the task 5021 or 5022 issues a reception request to the queue 5001, if there is data in the queue 5001, the data is sent from the queue 5001. If the queue 5001 is empty, the reception request is blocked until the queue 5001 receives data.

If tasks 5011 or 5012 send data to queue 5001, those tasks are not blocked.

FIG. 6 is a sequence diagram showing an operation example of the inter-task interface shown in FIG. 5, showing an example in which the cases are classified according to the order relation of transmission and reception.

Case A is one of receiving tasks (502 in the figure).
It shows a case where one of the transmission tasks (5011 in the figure) issues a transmission event to the queue 5001 in the state where the reception request was issued earlier by 1). In this case, queue 50
Task 5021 that issued a receive request to 01 and was blocked
Is released when the task 5011 issues a send event, and becomes ready for execution.

In case B, one of the transmission tasks (5011 in the figure) first issues a transmission event to the queue 5001.
After that, one of the receiving tasks (5021 in the figure) is queue 5001.
The case where the reception request is issued is shown in FIG. In this case, the reception request of the reception task 5021 is immediately accepted, and the reception task 5021 receives the data transmitted by the transmission task 5011.

In case C, two sending tasks are queued to 500
This shows a case where a send event is issued to 1 and then one of the receive tasks (5021 in the figure) issues two receive events to the queue 5001 in succession. in this case,
The reception task 5021 receives the transmitted data on a first-come-first-served basis (first-in first-out system) without being blocked. If the sending event is issued to the queue 5001 successively, the same number of receiving events are triggered, so that the sending event to the queue 5001 has a cumulative effect.

In case D, two receiving tasks are queued to 500.
After issuing a reception request to 1, one of the transmission tasks (5011 in the figure) issues a transmission event to the queue 5001. In this case, of the two blocked reception tasks, the task with the higher priority (task 5022 in the figure) receives the transmission data and becomes ready to execute. The other receiving task 5021 remains suspended.

FIG. 7 is a diagram showing an event-response protocol necessary for the multitask software having the inter-task interface shown in FIG. 5 to operate according to the sequence diagram shown in FIG.

FIG. 6A faithfully expresses the event-response protocol, and the event and response are OR conditions.

FIG. 11B is a diagram in which the protocol shown in FIG. 11A is divided into two parts. Since the transmission events for the queue 5001 have a cumulative effect, both protocols are satisfied. It is equivalent to satisfying the protocol shown in (a).

FIG. 11C is a protocol in the protocol shown in FIG. 11A regardless of which transmitting task transmitted. If it is certain that the tasks to be sent to the queue 5001 are limited to 5011 and 5012, the protocol of FIG. 7C is equivalent to the protocol of FIG.

FIG. 6D is a protocol in the protocol shown in FIG. 6B regardless of which receiving task receives. Tasks received from queue 5001 are 5021 and 5022
If it is certain that it is limited to, the compatibility of the protocols of FIG. 7D is equivalent to the protocol of FIG.

FIG. 7E does not care which reception task receives in the protocol shown in FIG. 7C (or does not matter which transmission task in the protocol shown in FIG. ) Is a protocol. In the situation where the tasks sent to the queue 5001 are limited to 5011 and 5012, and the tasks received from the queue 5001 are limited to 5021 and 5022, the same figure (e)
The protocol shown in (a) is equivalent to the protocol shown in (a).

[Complex task-to-task interface (type
2)] FIG. 8 is a diagram showing a second example of a complex inter-task interface, in which one event flag 8001 fulfilling the inter-task synchronization function, a plurality of transmitting tasks 8011 and 8012, and a plurality of receiving the same bit positions are received. It shows a complex inter-task interface such that tasks 8021 and 8022 receive AND.

The transmission task 8011 sets (transmits) bit 7 of the event flag 8001, and the reception task 8012 sets bit 8
Set (send). The reception tasks 8021 and 8022 issue an AND reception request (confirm that both bits are set) for bit 7 and bit 8 of the event flag 8001, and after reception completion, the reception tasks 8021 and 8022 respectively Clear (send) bits 7 and 8 of event flag 8001.

FIG. 9 is a sequence diagram showing an operation example of the inter-task interface shown in FIG. 8, showing an example in which the cases are classified according to the order relation of transmission and reception.

Case A has two receive tasks 8021 and 8022.
Shows the case where two send tasks 8011 and 8012 issue send events after issue a receive request. In this case, the blocked reception tasks 8021 and 8022 can be simultaneously executed (broadcast) when bits 7 and 8 of the event flag 8001 are both set.

In case B, there are two transmission tasks 8011 and 8012.
Issue two send tasks, then two receive tasks 8021 and 8022
Shows the case in which the request is issued. In this case, the receiving tasks 8021 and 8022 are not blocked and the receiving request is immediately satisfied.

As in the case A, the case C shows the case where the two receiving tasks 8021 and 8022 issue the receiving request and then the two transmitting tasks 8011 and 8012 issue the transmitting event. Illustrates setting the bit again before it is received (and therefore cleared). The sequence diagram in this case is the same as in case A. Eventually, event flag 8
The transmission event for 001 indicates that there is no accumulation effect.

FIG. 10 is a diagram showing an event-response protocol necessary for the multitask software having the inter-task interface shown in FIG. 8 to operate according to the sequence diagram shown in FIG.

FIG. 11A is a faithful representation of the event-response protocol, where the event and response are each AN.
D condition.

FIG. 11B is a diagram in which the protocol shown in FIG. 11A is divided into two. Tasks 8021 and 8022 do not receive a reception event unless bit 7 and bit 8 are set. Such division is possible.

FIG. 7C is a protocol in the protocol shown in FIG. 7B regardless of which transmission task transmitted. If the task of setting and clearing bits 7 and 8 of the event flag 8001 is sure to be 8011, 8012, 8021, 8022, the compatibility of the two protocols in the same figure (c) is shown in the same figure (b). It is equivalent to the compatibility of the two protocols and (a) in the figure.

[Event-Response Expression Conversion] FIG. 11 is shown in FIG.
FIG. 11 is a diagram showing rules for converting the event-response expressions shown in FIGS. 7 and 10 into a simpler expression format.

The first line in FIG. 10A shows that for event E,
It indicates that responses must be made in the order of responses R1 and R2 (hereinafter, such a case is referred to as "procedural response combination"). If the event has a cumulative effect, the same figure
It can be broken down into two independent event-response protocols, shown in the second and third lines of (a). For events that don't have a cumulative effect, there are timing issues,
In general, such decompositions are not equivalent.

The first line in FIG. 10B shows that for event E,
It indicates that the responses R1 and R2 must all respond (hereinafter, such a case is referred to as "AND type response combination"). If the event has a cumulative effect, the same figure
It can be broken down into two independent event-response protocols, shown in lines 2 and 3 of (b). For events that don't have a cumulative effect, there are timing issues,
In general, such decompositions are not equivalent.

The first line in FIG. 6C shows that the response R must respond when the event E1 is followed by the event E2 (hereinafter, such a case will be referred to as "procedural type"). "Event combination"). In the case of events that have a cumulative effect, as shown in the second and third lines of Figure (c),
It can be broken down into two independent event-response protocols. For events that do not have a cumulative effect, timing issues arise and such decompositions are generally not equivalent.

The first line in FIG. 6 (d) shows the event E1 or E2.
Indicates that the response R must respond when the occurrence of the event occurs (hereinafter, such a case is referred to as “OR type event combination”). With or without cumulative effects, it can be broken down into two independent event-response protocols, shown in the second and third lines of Figure (d).

In cases other than the above (for example, OR type response connection and AND type event connection), it seems that there is no simple decomposition rule. However, like the protocol shown in FIG. 7 (d), it is possible to simplify the expression of the OR type response coupling protocol by a method that does not specify the receiving task.
In addition, it is possible to simplify the expression of the AND-type response coupling protocol (which occurs when AND reception of event flags) by the method of paraphrasing the response like the protocol shown in FIG. 10 (b). is there.

[Detection of Inter-Task Interface Violation] Next, a method for the multi-task monitor 1005 to detect the inter-task interface violation of the multi-task software according to the event-response table will be described. In addition,
In the following description, the data structure will be described first with reference to FIGS. 12 to 17, and then the violation detection procedure using the data structure will be described with reference to FIGS. 18 to 25.

[Data Structure] FIG. 12 is a diagram showing an example of an event-response data structure representing an event and a response. A type field 12001 represents a task or resource, or in the case of a resource, a resource type. This field stores the symbol constant.
ID field 12002 follows type field 12001
This field stores the task or resource ID. The operation field 12003 is a field that stores an operation identifier of an event or a response. The value field 12004 is a field for storing a value unique to the operation target resource of the event or the response.

FIG. 13 is a diagram showing a detailed example of the event-response data structure, and shows the occurrence targets of events and responses according to tasks and resources, and in the case of resources, depending on the resource type. .

FIG. 9A shows an event for a queue-
In the details of the response data structure, the type field is always the symbol constant "TASK", and the task ID of the action subject or "0" is stored in the ID field when the task is not specified. In the operation field, the operation identifier “send”, “receive” or “reception request” is stored. Do not use the value field.

FIG. 11B shows the details of the event-response data structure for the event flag. The type field and ID field are the same as in FIG. "Set", "Clear", "Send" of the operation identifier in the operation field
It stores “reception” or “reception request”. In the value field, when the identifier of the operation field is "set" or "clear", the bit pattern for bit operation with the event flag is stored, and in the case of other identifiers, the bit position of the event flag is targeted. Stores a bit mask indicating whether.

FIG. 11C shows the details of the event-response data structure for a semaphore, and the type field and ID field are the same as in FIG. In the operation field, the operation identifier “send”, “receive” or “reception request” is stored. The value field stores the number of semaphore resources to be transmitted or received.

FIG. 6D shows an event for a task-
In the details of the response data structure, the type field stores the symbol constants "QUEUE", "FLAG", and "SEMAPHORE" indicating the type of resource to be operated by the task, and identifies the queue, event flag, and semaphore, respectively. The ID field stores the ID of the resource specified in the type field. The operation field and the value field are the same as the figure (a) when the type is "QUEUE", the figure (b) when it is "FLAG", and the figure (c) when it is "SEMAPHORE". Is.

FIG. 14 is a diagram showing an example of an event-response protocol structure which is an element in the event-response table 1002. A mode field 14001 is a field showing whether or not there is a cumulative effect of event occurrence. In the following, the case where there is a cumulative effect is referred to as “coefficient mode”, and the case where there is no cumulative effect is referred to as “binary mode”.

The excitation number field 14002 is a field for counting the number of event occurrences for which a response has not been executed after the event occurrence. When the mode field is "coefficient mode", the excitation number field is an integer greater than or equal to zero, and when it is "binary mode", it is 0 or 1.

The event field 14003 and the response field 14004 each store an event-response data structure. Procedure / AND / OR Do not consider combined event and response. Following the method described in Figure 11, it is necessary to express the specification of the task-task interface as a simple event-response pair.

The permissible time field 14005 stores a value representing the permissible time until the response is executed after the occurrence of the event, in system clock units. If the response is not executed within this allowed time, it is interpreted as a violation of this event-response protocol.

The link field 14006 is a field for linking the event-response protocol structures in a list.

FIG. 15 is a diagram showing an example of the excitation response structure used to detect the execution of the response to the event. The event-response structure link field 15001 indicates the event-response for which the response has not been executed after the event occurs. A field that points to a structure.

The remaining time field 15002 is a field showing the remaining time that the response must be executed, and it is the forward link field 15003 and the backward link field 1503.
04 is a field used to connect the excitation response structures in a bidirectional list.

FIGS. 16A and 16B are diagrams showing an example of the data structure in the multitask monitor 1005 which is changed for checking the inter-task interface. The extended task control block (extended TBC) 16001 shown in FIG. 16A is shown. Is an extension of TCB1006 that manages tasks for inspection of task-to-task interfaces. The extended part event-response list 16012 stores a pointer to a list of event-response protocols for tasks managed by the TBC 1006. Similarly, the excitation response list 16013 of the extension portion stores a pointer pointing to the list of the corresponding excitation response structures.

The extended resource control block 16002 shown in FIG. 16B is an extension of the resource control block for managing resources.
Similar to 01, with an expanded portion of the event-response list 16022 and excitation response list 16023.

FIG. 17 is a diagram showing an example of a dynamic link structure of the data structure shown in FIGS. 14 to 16B, and 17001 is an extended TBC.
Or resource control block, 17002 is the event-response protocol list for the task or resource managed by control block 17001, 17003
Is a list of excitation response structures whose response execution is checked.

A pointer pointing to the first element of the event-response protocol list 17002 is stored in the event-response protocol list field of the control block 17001, and the first element of the excitation response structure list 17003 is stored in the excitation response list field. The pointer that points to is stored.

[Violation Detection Procedure] FIG. 18 is a flowchart showing an example of processing executed by the multitask monitor 1005 when a service request is issued from the multitask monitor to the multitask monitor 1005. Steps S181 and S186 are multitask monitor. 1005 normal processing, step
S182, S183, and S185 are processes added to check the event-response protocol.

Step S182 is a procedure call for checking the event-response list for the task being executed. Note that which task is being executed is managed by the multitask monitor 1005.

Step S183 is a call to a procedure for checking the event-response list for the resource to be serviced. The service target resource ID is included in the service request invocation parameter.

Step S184 is a call of a procedure for checking the excitation response list for the task being executed, and step S185 is a call of a procedure for checking the excitation response list for the resource to be serviced.

FIG. 19 shows that when the timer service of the multitask monitor 1005 is called from the multitask software to notify the basic clock, the multitask monitor 10
In the flowchart showing an example of the process executed by 05, steps S191 and S193 are normal processes of the multitask monitor 1005, and step S192 is a process added to check the event-response protocol. Step S192
Is a call to the procedure for checking the timeout of the excitation response list for all tasks and all resources.

FIG. 20 is a flowchart showing an example of a procedure for checking the event-response list and detecting the occurrence of an event in the list, which is a procedure called from steps S182 and S183 shown in FIG. In the figure, step S201
Then, the first element (event-response protocol structure) of the event-response list specified by the parameter is fetched.
Next, in steps S202 and S204, the elements of the list are sequentially fetched, and a procedure for checking the occurrence of an event is called for the event-response protocol structure fetched in step S203.

FIG. 21 is a flow chart showing an example of the procedure for checking the excitation response list and detecting the execution of the excitation response in the list, which is the procedure called from steps S184 and S185 shown in FIG. In the figure, in step S211, the head element (excitation response structure) of the excitation response list designated by the parameter is taken out. Next, in steps S212 and S214, the elements of the list are fetched one after another, and the procedure for checking the execution of the excitation response is called for the excitation response structure fetched in step S213.

FIG. 22 is a flow chart showing an example of the procedure for detecting the timeout of the excitation response in the excitation response list, which is the procedure called from step S192 shown in FIG. In the figure, in step S221, the head element (excitation response structure) of the excitation response list designated by the parameter is taken out. Next, in steps S222 and S224, the elements of the list are fetched one after another, and the procedure for checking the timeout of the excitation response is called for the excitation response structure fetched in step S223.

FIG. 23 is a flow chart showing an example of the procedure for detecting the occurrence of an event for the task or resource specified by the parameter and for the event-response protocol structure specified by the parameter, which is shown in FIG. This is the procedure called from step S203. In the figure, in step S231 and step S232, the event
-Examine the mode and excitation number fields of the response protocol structure and return immediately if "binary mode" and the excitation number field is positive.

Next, in steps S233 and S234, the type of the event field (event-response data structure), I
Compare the D, Behavior, and Value fields and if they don't match, that is, if no event has occurred, return immediately.

Next, in step S235, a memory area for the excitation response structure is allocated, the value of the allowable time field of the event-response protocol structure is copied to the remaining time field, and the event is written to the event-response protocol link field. -Set the address of the response protocol structure and add it to the excitation response list of the task or resource specified by the parameter, ie set the forward link or backward link field appropriately.

Next, in step S236, the excitation number field of the event-response protocol structure is incremented.

FIG. 24 is a flow chart showing an example of the process for detecting the execution of the excitation response for the excitation response structure designated by the parameter, which is the procedure called from step S213 shown in FIG. In the figure, in step S241,
The corresponding event-response protocol structure is acquired from the value of the event-response protocol link field of the excitation response structure specified by the parameter.

Next, in steps S242 and S243, an event-
The response field (event-response data structure) type, ID, action, and value fields of the response protocol structure are compared, and if they do not match, that is, no response is detected, an immediate return is made.

Next, in step S244, the excitation number field of the event-response protocol structure is decremented, in step S245 the excitation response structure is removed from the excitation response list, and the memory area allocated to the structure is released. .

FIG. 25 is a flowchart showing an example of a procedure for detecting the timeout of the excitation response structure designated by the parameter, which is the procedure called from step S223 shown in FIG. In the figure, in steps S251 and S252, the remaining time field of the excitation response structure designated by the parameter is decremented, and if the resulting remaining time field is positive, the process immediately returns. If the remaining time field becomes zero, a timeout has occurred,
In this case, the communication device 1008 shown in FIG.
Error notification using the event-response protocol link field of the excitation response structure in step S254,
Acquire the corresponding event-response protocol structure, decrement the excitation number field of the event-response protocol structure in step S255, remove the excitation response structure from the excitation response list in step S256, occupied by the excitation response structure. The memory area that was previously released.

As described above, according to this embodiment, it is possible to automatically detect an error in the inter-task interface without examining the operation of the multi-task software in detail. Therefore, by checking the inter-task interface specification, it is immediately known which task is the cause of the software defect phenomenon, and the time lag from the appearance of the phenomenon to the countermeasure can be shortened.

Furthermore, the software inspection method of this embodiment can be immediately used when developing multitasking software of hardware having only a simple communication device.

[0104]

[Other Embodiments] Even if the present invention is applied to a system including a plurality of devices (for example, a host computer, an interface device, a reader, a printer, etc.), an apparatus (for example, a copying machine) Machine, facsimile machine, etc.).

Further, an object of the present invention is to supply a storage medium having a program code of software for realizing the functions of the above-described embodiments to a system or apparatus, and to supply the computer (or CPU or M or M) of the system or apparatus.
Needless to say, this can also be achieved by the PU) reading and executing the program code stored in the storage medium. In this case, the program code itself read from the storage medium implements the functions of the above-described embodiment, and the storage medium storing the program code constitutes the present invention. Examples of the storage medium for supplying the program code include a floppy disk, a hard disk, an optical disk, a magneto-optical disk, a CD-ROM,
CD-R, magnetic tape, non-volatile memory card, ROM, etc. can be used.

Moreover, not only the functions of the above-described embodiments are realized by executing the program code read by the computer, but also the OS or the like running on the computer is actually executed based on the instructions of the program code. It goes without saying that a case where a part or all of the processing of (1) is performed and the functions of the above-described embodiments are realized by the processing is also included.

Further, after the program code read from the storage medium is written in the memory provided in the function expansion board inserted into the computer or the function expansion unit connected to the computer, based on the instruction of the program code, It goes without saying that a case where the CPU or the like included in the function expansion board or the function expansion unit performs a part or all of the actual processing and the processing realizes the functions of the above-described embodiments is also included.

[0108]

As described above, according to the present invention,
It is possible to provide a software inspection method and apparatus for detecting an error in an inter-task interface without examining the operation of multitask software in detail.

[Brief description of the drawings]

FIG. 1 is a functional block diagram showing a configuration example of a software inspection device according to an embodiment of the present invention,

FIG. 2 is a diagram showing a typical multitasking software,

FIG. 3 is a sequence diagram showing a time-series operation example of the multitask software shown in FIG.

[Fig.4] Event interface protocol between tasks
-Diagram represented by response expression,

FIG. 5 is a diagram showing an example of a complex inter-task interface,

6 is a sequence diagram showing an operation example of the inter-task interface shown in FIG.

7 is a diagram showing an event-response protocol necessary for the multitasking software having the intertask interface shown in FIG. 5 to operate according to the sequence diagram shown in FIG. 6;

FIG. 8 is a diagram showing a second example of a complex inter-task interface,

9 is a sequence diagram showing an operation example of the inter-task interface shown in FIG.

10 is a diagram showing an event-response protocol necessary for the multitask software having the intertask interface shown in FIG. 8 to operate according to the sequence diagram shown in FIG. 9;

FIG. 11 is a diagram showing a rule for converting the event-response expression shown in FIGS. 4, 7, and 10 into a simpler expression format;

FIG. 12 is a diagram showing an example of an event-response data structure representing an event and a response,

FIG. 13 is a diagram showing a detailed example of an event-response data structure,

FIG. 14 is a diagram showing an example of an event-response protocol structure that is an element in an event-response table;

FIG. 15 is a diagram showing an example of an excitation response structure used for detecting execution of a response to an event,

FIG. 16A is a diagram showing an example of a data structure in a multitask monitor which is changed for checking an interface between tasks;

FIG. 16B is a diagram showing an example of a data structure in a multitask monitor which is changed for checking an interface between tasks;

FIG. 17 is a diagram showing an example of a dynamic link structure of the data structure shown in FIGS. 14 to 16B;

FIG. 18 is a flowchart showing an example of processing executed by the multitask monitor when a service request is issued from the multitask software to the multitask monitor;

FIG. 19 is a flowchart showing an example of processing executed by the multitask monitor when the timer service of the multitask monitor is called from the multitask software to notify the basic clock.

FIG. 20 is a flowchart showing an example of a procedure for examining an event-response list and detecting occurrence of an event in the list.

FIG. 21 is a flow chart showing an example of a procedure for examining an excitation response list and detecting execution of an excitation response in the list.

FIG. 22 is a flowchart showing an example of a procedure for detecting a timeout of an excitation response in the excitation response list.

[Fig. 23] An event specified by a parameter for a task or resource specified by a parameter-
A flowchart showing an example of a procedure for detecting the occurrence of an event for a response protocol structure,

FIG. 24 is a flowchart showing an example of processing for detecting execution of an excitation response with respect to an excitation response structure specified by a parameter;

FIG. 25 is a flowchart showing an example of a procedure for detecting a timeout of an excitation response structure designated by a parameter.

Claims (6)

[Claims] 1. A software inspection method, wherein the multitask software is inspected by operating the multitask software in real time and detecting a violation of a preset interface specification between tasks. 2. The interface specification between tasks is expressed by a set of a pair of an event corresponding to each task and a resource commonly accessed between the tasks and a response to the event. Described software inspection method. 3. The software inspection method according to claim 2, wherein the resources include queues, semaphores, and event flags. 4. Software for inspecting multitask software operating on hardware equipped with a low-speed communication device by incorporating the software inspection method according to claim 1 into a multitask monitor. Inspection device. 5. The multi-task monitor monitors the operation related to the inter-task interface specification of the multi-task software externally set in the table, and notifies the interface protocol violation to the outside using the communication device. The software inspection device according to claim 4, wherein 6. The multitask monitor activates a corresponding response when detecting the occurrence of an event related to the inter-task interface specification, and outputs an error to the outside when the response is not executed within a predetermined allowable time. 6. The software inspection device according to claim 5, wherein the software inspection device is notified.