EP2159695A2 - Testing system - Google Patents

Abstract

The system (1) has a test stand (2) e.g. hardware-in-the-loop-system, for testing a controlling process of a target system (3) and comprising a real-time adapter (6) with a microprocessor (7) and input/output systems (8). A computer unit (12) has a memory unit (11) for storing parameters describing hardware and software-specifications of the test stand. A configuration-management-system (14) checks hardware and software-specifications of another test stand, such that a degree of correlation of the specifications of the latter test stand with the parameters is determined.

Description

The invention relates to a test system.

In technically complex systems such as process controls for conveyors, parcel sorting systems and the like, extensive functional tests of the respective target system are required already in the development stage and in particular in the prototype phase or in the pilot series.

In order to carry out such functional tests, test stands are generally used, with the term test bench in the following being intended to include any device for such a performance of functional tests of a target system. In such a test stand, if possible under real conditions, a simulation of specific functions of the target system takes place. For carrying out such simulations, a suitable simulation software, a software environment for the integration of components of the target system to be tested and a hardware environment suitable for this purpose are required.

In the functional testing of complex target systems, the software and hardware structure of the test bench is correspondingly complex and adapted to the respective target system.

A major problem is the traceability of such systems. As a result of changing versions, as well as changes in the scope of functions and the manufacturing structure of a target system, the test stands intended for this purpose also change over time. Continue to be already Due to discontinuation of software and hardware products inevitably changes in the construction of the test benches over time.

For example, in the event of a fault in a target system used in production, it may be necessary to repeat a test performed a year before with a test bench. This may be necessary, for example, to clarify liability issues in the event of an error. If the test bench no longer exists in its former structure, a reproducible repetition is no longer possible, since even if the design documents of the test bench are still available, its exact replica is no longer possible because typically essential software and hardware products are not more are available. Often it is even the case that the design documents contain only incomplete information about the structure and functionality of the test bench, so that it is not possible to duplicate an old test bench or compare it with a recent test bench.

The invention has for its object to provide a test system by means of which a traceability of test benches is made possible.

To solve this problem, the features of claim 1 are provided. Advantageous embodiments and expedient developments of the invention are described in the subclaims.

The test system according to the invention comprises a memory unit in which parameters can be stored. The parameters describe the software and hardware specification of a test bench. Furthermore, checking means are provided for checking the software and hardware specification of at least one further test stand. With these, the degree of compliance of the software and hardware specification of the other test stand with the stored parameters in the computer unit can be determined.

The fact that the complete hardware and software specifications of test stands are stored as parameters, preferably in the form of a single characteristic file, ensures complete traceability of the test stands. In particular, based on the stored parameters, a specific status of a test bench at a specific development time can be defined exactly and compared with other test benches. Finally, by resorting to a hardware and software specification defined by the parameters, it is also possible to re-create this test bench after years.

Particularly advantageous in the test benches a driver software is integrated, in addition to their basic functions to issue queries to the target system to be tested and receive responses from the target system thereon, the generation of the characteristic file agrees. The generation of the characteristic file is thus carried out on site in the test bench, that is without the use of external units.

The storage of the characteristic file, however, takes place on an external unit, in particular a computer unit. Furthermore, the driver software of a test bench also takes on the task of a checking means such that for the comparison of the hardware and software specification of this test bench it is compared with a characteristic file stored in the computer unit.

This comparison allows the driver software to determine if the hardware and software specification of the test bench matches the hardware and software specification of another test bench defined by the parameter file.

Particularly advantageously, the comparison is made in such a way that an assessment is possible as to whether the test benches to be compared are identical, if not, if they are at least functionally identical, or if no, where functional deviations are present.

Such a comparison is of great advantage in particular if a previous test stand is to be simulated on the basis of the stored characteristic data files. An identical replica is present if the software and hardware components not only fulfill the same functions but are also identical in design.

In particular, if a test rig structure is to be modeled that is already several years old, it is probable that not all software and hardware components that were used in the old test bench will be available for the new test bench. In this case, a significant advantage of the test system according to the invention is that based on the characteristics file an automatic comparison of the functions can be performed from different software and hardware components to then output either the match or non-compliance of the functions as output. In the first case, approval is given by the comparison on the basis of the characteristic file in the test system that the same scope of testing is guaranteed with both test benches. In the second case, the output deviations are preferably specified in such a way that the functional compatibility with the old test bench can be restored by deliberately replacing components used in the new test bench.

Figur 1:

Darstellung eines Prüfsystems mit einem ersten Prüfstand bei Abspeichern einer dem Prüfsystem kennzeichnenden Kenngrö- ßendatei in einer Speichereinheit.

Figur 2:

Darstellung eines Prüfsystems mit einem zweiten Prüfstand bei Auslesen der Kenngrößendatei des ersten Prüfstands gemäß Fi- gur 1.

The invention will be explained below with reference to the drawings. Show it:

FIG. 1:

Presentation of a test system with a first test bench when storing a characteristic file identifying the test system in a memory unit.

FIG. 2:

Presentation of a test system with a second test bench when reading the parameter file of the first test bench according to FIG. 1.

FIG. 1 schematically shows the structure of the test system according to the invention 1. The test system 1 comprises a test bed 2, which serves for functional testing of a target system 3. The test stand 2 can be designed in particular as a hardware-in-theloop system for testing control processes. The target system 3 may be formed by a process controller. The target system 3 generally includes target hardware and target software installed thereon.

The test bench 2 according to FIG. 1 comprises a computer in the form of a personal computer (PC) 4. This is a simulation software, hereinafter referred to simulation module 5, installed, which serves for functional testing of the target system 3. The simulation module 5 consists of a plurality of software modules.

The test stand 2 further includes a real-time adapter 6. The real-time adapter 6 forms in the present case a working according to the master-slave principle system with a master in the form of a microprocessor 7 or the like and with slaves in the form of I / O systems 8, the CAN buses, LIN buses or the like may be formed and which connect to the target system 3. Via a driver software 9, a bidirectional data exchange takes place between the simulation module 5 and the real-time adapter 6.

While the scope of the simulation is predetermined by the simulation module 5, the time behavior of the simulation is determined by the real-time adapter 6, provided by means of a present in the real-time adapter 6 time base from the target system 3 signals read with time stamps and entered with these in the simulation module 5, and signals generated in the simulation module 5 are supplied to the target system 3 by the real-time adapter 6 at set times defined in the simulation module 5. The time base available for this purpose in the real-time adapter 6 can be a local time base, which is specified, for example, by a clock in the real-time adapter 6. Particularly advantageously, the real-time adapter 6 has an absolute time base, so that in the real-time adapter 6 signals that are read from the target system 3, are provided with absolute timestamps. For this purpose, the real-time adapter 6 expediently has an interface (not shown) for reading in absolute time signals, in particular GPS signals.

By using the real-time adapter 6, the target system 3 can be tested with the original target hardware and software.

The driver software 9 of the test bench 2 includes an API (application programmable interface) module 10, by means of which a parameter file consisting of parameters describing the complete software and hardware specification of the test bench 2 is automatically generated. The characteristic file is designed in the present case as an XML file. In general, of course, other file formats are possible. The parameters generated in the API module 10 comprise information structured in several information levels about the software and hardware components of the test bench 2.

In the case of the software components, these are, for example, information about whether software modules are standard or special modules. Furthermore, versions of the software modules as well as information about the functional scope of the software modules are included as parameters.

In the case of hardware components, the information includes information about manufacturers, version numbers and manufacturing data. Furthermore, information about the functions of hardware components is also part of the parameters, for example for the slaves of the test bench 2 information about which units they can be connected to.

Such a test bench 2 characterizing characteristics file that is generated in the API module 10 is stored in an external memory unit 11, which is part of a computer unit 12. The computer unit 12 also has a processor 13, on which among other things a configuration management system 14 is implemented. In the configuration management system 14, the software of the test bench 2 can be stored in a complete version management. By storing the parameter file, the complete software and hardware specification of the test bench 2 is stored in the memory unit 11. In general, a plurality of such characteristic data files for different test stands 2 can be stored in the memory unit 11.

FIG. 2 shows a further test system 1, wherein the computer unit 12 according to FIG. 1 having. For this purpose, the characteristic data file is stored in the memory unit 11, which corresponds to the software and hardware configuration of the test stand 2 in accordance with FIG FIG. 1 equivalent.

FIG. 2 further shows a test stand 2, the test bench 2 in terms of structural design according to FIG. 1 equivalent. The test bench 2 according to FIG. 2 should be examined to the extent to which this the test bench 2 in accordance with FIG. 1 equivalent.

For this purpose, as in FIG. 2 shown schematically, the characteristic file read from the memory unit 11 and the API module 10 of the test bench 2 according to FIG. 2 made available.

This API module 10 forms a checking means such that it is automatically checked on the basis of the characteristic file, whether the software and hardware configuration of the test bench 2 in accordance with FIG. 1 with that of the test bench 2 according to FIG. 2 is identical or functionally identical.

An identity exists if exactly the same software and hardware components are used for both test benches 2. This can easily be done by balancing product data contained in the characteristic file.

Since the characteristic file also contains information about the functionalities of the software and hardware components, it is possible with the API module 10 of the test bench 2 in accordance with FIG FIG. 2 It can also be ascertained whether the use of software and hardware components which are not identical to the components contained in the characteristic quantity file still ensures functional equality.

If so, API module 10 outputs this as the output size. If this is not the case, the software and hardware components for which there are functional deviations are preferably output. On the basis of which the user can replace them with other components in order to achieve the desired functional uniformity of the test bench 2 according to FIG FIG. 2 with the test bench 2 defined in the parameter file.

Finally, by using the configuration management system, the software configuration of the test bed 2, in particular of the master-slave system of the test bed 2, be created automatically.

The configuration management system contains all information necessary for the construction of the test bench software, in particular the listing and linking of the individual software modules of the test bench 2.

LIST OF REFERENCE NUMBERS

(1)

Test System

(2)

test bench

(3)

target system

(4)

personal computer

(5)

simulation module

(6)

Real Time Adapter

(7)

microprocessor

(8th)

I / O system

(9)

driver software

(10)

API module

(11)

storage unit

(12)

computer unit

(13)

processor

(14)

Configuration Management System

Claims (12)

Test system (1), with a memory unit (11) are stored in which characteristics, by means of which the software and hardware specification of a test stand (2) are described, and with checking means for checking the software and hardware specification of at least one further test bench (2), with which the degree of conformity of the software and hardware specification of the further test stand (2) with the parameters stored in the computer unit (12) can be determined. Test system according to claim 1, characterized in that the parameters are stored in a characteristic file. Test system according to claim 2, characterized in that the characteristic file is generated by means of a driver software (9) which is part of the test stand (2). Test system according to one of claims 1 to 3, characterized in that the checking means comprise driver software (9). Test system according to claim 4, characterized in that the driver software (9) is part of the further test stand (2). Test system according to claim 5, characterized in that the driver software (9) of the further test stand (2) is functionally identical to the driver software (9) of the test bench (2). Test system according to one of claims 1 to 6, characterized in that it can be determined by the checking means, whether the software and hardware specifications of the test stand (2) and the further test stand (2) are identical or functionally identical. The inspection system according to claim 7, characterized in that are identifiable and can be documented with the verification means deviations of the software and hardware specifications of the bench (2) and the other dynamometer (2). Test system according to one of claims 7 or 8, characterized in that on the basis of the characteristic file by means of the checking means, the software configuration for the further test stand (2) is automatically genierbar. Test system according to claim 9, characterized in that the means for checking comprise a configuration management system. Test system according to one of claims 1 to 10, characterized in that the parameters contain manufacturer-specific information and information about the functional scope of the software and hardware. Test system according to claim 11, characterized in that the parameters in different levels contain structured information about the software and hardware.

Images