Data processing: software development – installation – and managem – Software program development tool – Testing or debugging
Reexamination Certificate
2000-04-20
2004-06-15
Dam, Tuan (Department: 2122)
Data processing: software development, installation, and managem
Software program development tool
Testing or debugging
C717S124000, C717S131000, C714S030000, C714S034000, C714S037000, C714S047300, C712S040000, C712S244000
Reexamination Certificate
active
06751788
ABSTRACT:
BACKGROUND OF THE INVENTION
Field of the Invention
The invention relates to a method of testing computer software.
Software and sections of software (called software modules below) are presently frequently written by more than one person. It is, therefore, necessary to ensure that the actions of one software module do not contradict, or even reverse, those of another software module. In the case of open software, that is to say, in the environment of a personal computer, the mutual independence and compatibility of the software modules is guaranteed by dynamic area monitoring software.
For software embedded in devices (with microcontrollers, microprocessors, or controllers, for example), the compatibility is currently ensured by rules for the cooperation of individual software modules: the software is first produced in readable form as source code with the associated documentation. The software is then compiled into the machine-readable form, the object code. A company's in-house task division and rules (design rules) ensure that the individual software modules are compatible with one another. The interaction of the software modules in terms of function and timing is checked in an integration test.
In the case of embedded software, all these operations are carried out with the open cooperation of all those involved, that is to say, with the source codes and their documentation at hand.
Embedded software modules executing cooperative functions between two or more devices have become so complex that they can no longer be mastered or produced by individual firms alone. It has become necessary for competitors to cooperate in producing the embedded software for one or more devices. However, the competitive situation between the firms forbids the disclosure of the source code and necessitates that object code that is already compiled be embedded. Consequently, the content of a technical function is no longer known in detail to the producer of another function. The producer, therefore, can no longer take the content into account.
For a software module to perform its technical functions independently of and compatibly with another technical function, an additional area monitoring function would need to be installed. However, such installation is relatively complex, and, hence, expensive.
Software tools exist that can check that formal rules (design rules) in the source code or in the object code are being observed. There are also mechanisms for worst-case prediction of the time response using the source code or object code. However, there is no method for checking the mutual independence and compatibility of various technical functions implemented by software.
SUMMARY OF THE INVENTION
It is accordingly an object of the invention to provide a method of testing computer software that overcomes the hereinafore-mentioned disadvantages of the heretofore-known devices and methods of this general type and that checks the mutual independence and compatibility of various technical functions implemented by software.
With the foregoing and other objects in view, there is provided, in accordance with the invention, a method of testing the ability of software modules, each executing particular functions, in a device to cooperate using machine code sequences contained in executing software modules, including searching software modules for machine code sequences containing write access to unauthorized areas, ascertaining a respective maximum number of loop passes for each loop and establishing whether or not the respective maximum number of loop passes is limited, and if reference values are observed, determining that the software modules are able to cooperate, and, if the reference values are not observed, determining that the software modules are not able to cooperate.
One advantage of the invention is that no additional complexity (random access memory, read-only memory, run time) is required in the controller itself. The reduction in complexity is achieved, in particular, by the measures described below, where it is merely necessary to know the division of the technical functions between the individual software modules. Division of technical functions should be understood, for example, as meaning (1) which actuators, sensors and so on attend to which function through which ports, (2) which registers (e.g., for basic settings of the microcontroller, the microprocessor, or the controller) are attended to by which function, (3) how much run time should be available for the respective functions, (4) how frequently interrupts, preemptions and task calls will arise per unit of time, and (5) which interfaces use the functions amongst one another.
The method according to the invention for formally checking and testing software modules that are to be embedded, and appropriate complete software that is embedded, provides for the properties of the individual software modules, in terms of delimitation from the other software modules, to be formally checked statically and quasi-dynamically (meaning static worst-case consideration of the dynamic response), and for carrying out the check even before the device is in dynamic operation. The result of the check is that, advantageously, no additional monitoring software is required in active operation.
Another advantage provided is that a serviceable general technical set of functions is ensured for devices with embedded software, particularly in applications in which sections of the software are not in the form of source code. In such a case, the formal check on the delimitation of the software modules relates at least (but no exclusively) to checking prohibited write access operations to memories (for example, to registers, random access memory areas, pins, pointers, etc.) and to checking the limitation of loop counters (for example, that there are no endless loops). It is also possible to check whether or not prohibited interrupt-enable/disable operations are being carried out.
As part of the function check, provision can also be made for (1) carrying out a check, based on the object code, to determine whether or not program sections are executed directly from the random access memory area (that is to say can be changed dynamically), (2) using the object code to check the maximum length of time for which an interrupt is disabled, (3) using the object code to check the maximum amount of time a software module (task) needs for processing, (4) for the object code for an implementation language (such as OSEK-OIL), particularly, the description of the task priorities, preemptions and so on, and using the indication of the task activation frequency to determine the worst-case time response of all or a subset of the software modules, and (5) ascertaining the stack size from the worst-case situation with regard to interrupts, preemptions, etc., and their priority and frequency.
In accordance with another mode of the invention, the software modules are searched for sequences in which unauthorized interrupt-enable/disable operations are carried out, and, if the reference values are observed, it is determined that the software modules are able to cooperate, and, if the reference values are not observed, it is determined that the software modules are not able to cooperate.
In accordance with a further mode of the invention, the interrupt-disable times are ascertained and the interrupt-disable times are compared with respectively appropriate reference values, and, if the reference values are observed, it is determined that the software modules are able to cooperate, and, if the reference values are not observed, it is determined that the software modules are not able to cooperate.
In accordance with an added mode of the invention, a maximum run time of the individual executing software modules is ascertained and the maximum run time of the individual executing software modules is compared with respectively appropriate reference values, and, if the reference values are observed, it is determined that the software modules are able to cooperate, and, if the reference val
Dam Tuan
Kendall Chuck
LandOfFree
Method of testing computer software does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method of testing computer software, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method of testing computer software will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3301769