Automated testing of applications

Abstract

The application proposes improving testing of automated applications. For this purpose, data for an automation language of a test environment is processed, the test environment comprising a test environment for a real system of the automation application and / or at least one simulated test environment for the automation application. Finally, at least one test of the test environment is performed. The advantage of this is that due to improved testing, higher safety of automated products can be achieved.

Description

Technical Field

[0001] The present invention relates to an innovative method for testing an automated product. Background Art

[0002] In automation products, it is very important to be able to check the safety of the application. For example, it aims to prevent industrial robots from performing movements into safety-critical areas, thereby endangering people or damaging machines or facilities. As automation products become more and more complex, this situation becomes increasingly difficult. For example, when machines perform complex processes and movements, their over-limit safety must also be guaranteed. As part of this, the procedures should be checked and certified from a safety-related point of view.

[0003] In the context of such checks, it is necessary to perform and create complex tests. This is usually done by manually entering different test scenarios. This is tedious, time-consuming, and often limited to a subset of relevant scenarios.

[0004] The specific problem is that the applications of automation products are defined in an “automation language”, which has limitations in terms of flexible and comprehensive testing.

[0005] For the purposes of this discussion "automation languages" include in particular programming languages ​​for programmable logic controllers, such as (but not limited to) those defined in the EN 61131-3 standard, including: Instruction List (STL), Contact Point Programming (KOP), Function Block Language (FBS, also known as Functional Programming (FBD) or STEP 7), Sequence Language (AS) or Structured Text (ST).

[0006] In this context, automation languages ​​are distinguished from so-called "high-level programming languages" (for example: Java, C, C++, JavaScript, C#, Python, PHP, etc.). Summary of the invention

[0007] One object is to provide improved processing for application programs of automation products, in particular for safety-related applications.

[0008] This object is achieved according to the features of the invention.Preferred embodiments can be found in particular in the present invention.

[0009] To achieve this goal, a method for testing automation applications is proposed.

[0010] - among others, processing data in an automation language for a test environment,

[0011] - wherein the test environment comprises a test environment of a real system for the automation application and / or at least one simulated test environment for the automation application,

[0012] - wherein at least one test of the test environment is executed.

[0013] Automation applications include, for example, real automation products or simulations of automation products. Automation products are, for example, automation systems and include, for example, automation units such as manufacturing machines, robots, and the like.

[0014] A further development is that the data of the automation language include elements or modules of the automation language provided to the test unit.

[0015] A further development is that the automation language is a programming language for a programmable logic controller, in particular a programming language according to or based on the 61131-3 standard.

[0016] Further, the data of the automation language for the test environment is processed according to at least one of the following operations:

[0017] - Extract input / output variables for the test environment;

[0018] -Adjust data types;

[0019] -Generate test classes based on automated language data.

[0020] A further development is to process the automated language data for the test environment on the basis of additional reference data.

[0021] A further improvement is to process the automated language data of the test environment based on the additional reference data according to the following operations:

[0022] - Mapping of the data to permitted values ​​or value ranges using reference data, wherein in particular adaptations can be made based on the data type.

[0023] A further development consists in that the verification is carried out by comparing a real system of the automation application with at least one simulation of the automation application.

[0024] A further development consists in that the verification is carried out by comparing at least two simulations of the automation application with one another.

[0025] A further development consists in that the elements of the automation language are converted into a program in a high-level programming language and at least one simulation of the test environment is generated or modified using the program.

[0026] A further improvement is to test the program.

[0027] A device for a test automation application is also proposed, the device comprising a processing unit configured to perform the steps of the method described herein.

[0028] The processing unit mentioned here can be implemented in particular as a processor unit and / or an at least partially hardwired or logic circuit arrangement, which is for example arranged to enable the method to be performed as described herein. The processing unit can be or include any type of processor or calculator or a computer with necessary peripherals (memory, input / output interface, input / output device, etc.).

[0029] The above explanations related to the method are correspondingly applicable to the device. The device can be designed in one component or distributed in multiple components.

[0030] The above-mentioned object can also be achieved by a system comprising at least one of the devices described herein.

[0031] In addition, a device for testing an automated application is proposed, comprising a test unit and a test environment.

[0032] - wherein the test unit is configured to process data in an automation language for a test environment,

[0033] - wherein the test environment comprises a test environment of a real system for the automation application and / or at least one simulated test environment for the automation application,

[0034] - wherein the test environment is further configured to perform at least one test.

[0035] The product proposed herein also comprises a computer program product capable of being loaded directly into the memory of a digital computer, the computer program product comprising program code portions adapted to execute the steps of the method described herein.

[0036] Furthermore, the above mentioned problem is also solved by a computer-readable storage medium, such as any desired memory, comprising instructions executable by a computer (eg in the form of program code) and adapted to cause the computer to perform the steps of the method described herein. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] The above-mentioned characteristics, features and advantages of the present invention, as well as the way to achieve these, will be more clearly understood and easily understood in conjunction with the schematic description of the following embodiment, which will be combined with a more detailed explanation and drawings. For the sake of clarity, the same or elements having the same effect can be provided with the same reference numerals.

[0038] The figure shows:

[0039] Figure 1 A schematic diagram illustrating generation of data for performing tests of an automated product is shown;

[0040] Figure 2 Shown based on Figure 1 A block diagram of an extended test environment;

[0041] Figure 3 Shown based on Figure 2 Block diagram of a test system with expanded testing capabilities. DETAILED DESCRIPTION

[0042] Figure 1 A schematic diagram illustrating generation of data for performing a test of an automation product is shown. The automation product can include a plurality of automation units, such as manufacturing machines, robots, and the like.

[0043] Block 101 comprises elements of an automation language. As mentioned above, it can be an automation language according to the EN61131-3 standard or a similar automation language. For example, the elements of the automation language define instruction libraries (also called libraries) (e.g. FBD libraries). The elements of the automation language can be provided in the form of modules, wherein each module comprises at least one function (function block, function call) and / or at least a series of instructions.

[0044] Figure 1 Also included is a test unit 102 . This is, for example, a test suite for at least one test to be executed on a test environment 103 .

[0045] The test environment 103 can include a real system 104 (ie a specific automation product) and / or (at least) one simulation 105 of the real system.

[0046] The test unit 102 is used to prepare at least one test on the test environment 103. Such preparation in the test unit 102 comprises, for example, extraction and / or preparation of information based on data provided by the block 101. In particular, the provision can involve a data query initiated by the test unit 102.

[0047] For example, data from the block 101 are transferred to the test unit 102. For this purpose, elements of an automation language from the block 101 can be transmitted to the test unit 102. For example, the data can be provided in XML (Extensible Markup Language) format.

[0048] Based on the acquired data, the testing unit 102 extracts information that can be subsequently used in the testing environment 103 .

[0049] Optionally, the test unit 102 processes the data by including reference data 106. The reference data 106 can be part of the test unit 102 and / or provided by a separate unit. The reference data 106 contains, for example, values ​​(ranges) of variables extracted by the test unit 102. For example, expected values ​​for a module can also be part of the reference data 106.

[0050] The processing of the data provided by block 101 and the optional reference data 106 on the test unit 102 comprises at least one of the following operations:

[0051] (1) Extracting input / output variables related to the test environment 103; these are, for example, external variables that are visible to the outside and affect the test environment 103, while internal (local) variables of elements of the automation language can be omitted. In one example, external variables can be distinguished from internal variables, for example, based on the declaration part of the automation language. These variables are suitable for, for example, evaluating the success (or possibly failure) of the test.

[0052] (2) Data types can be adjusted. For example, the data types of the automation language can be adjusted to the data types of the test environment 103 .

[0053] (3) The extracted variables can be mapped to allowed values ​​or value ranges using reference data 106. Adjustments can also be made based on different data types.

[0054] (4) The processing of data (optionally taking into account reference data 106) is module-dependent, i.e. depends on the module defined in block 101. In particular, the module can be identified as such and transformed (prepared) accordingly for the test environment. For example, such transformation can include mapping the classes present in the F-FUP with the associated methods and variables so that they can be checked when executing the test (test environment 103).

[0055] (5) Generate test classes based on automated language data.

[0056] The test unit 102 therefore transfers information (in the form of data) to the test environment 103 , with which information tests can be performed on the real system 104 and / or on the simulation 105 .

[0057] Hence, automated tests can be prepared in an efficient manner, ie in particular determined and initiated or executed, based on elements available in an automation language, optionally using reference data, and the results checked.

[0058] Figure 2 Shown based on Figure 1 A block diagram of an extended test environment 103 is shown.

[0059] If, according to the above statements, the test environment 103 is determined by means of the test unit 102, the real system 104 can be tested and the simulation system 105 can be tested. Preferably, a comparison between the operation of the real system 104 and the (simulated) operation of the simulation 105 can be performed and a verification can be performed based on deviations: if the real system 104 and the simulation 105 behave identically (within predetermined limits), the verification can be verified, otherwise it cannot be verified and a search for the cause of the deviation can be initiated, for example.

[0060] The real system 104 can also include a reference implementation from an automation product, such as a test setup having an automation unit or a part of an automation unit.

[0061] The test environment 103 also enables the reference data 106 or parts of the reference data to be checked. For example, calibration ranges can be specified based on the reference data 106, which are checked and, if necessary, verified in the test environment. Optionally, the reference data 106 is appropriately prepared or converted by means of the test unit 102, so that its use is possible in the test environment 103.

[0062] Furthermore, as part of the simulation 105, different simulations can be performed based on the information determined by the test unit 102. In the present example, a SIMATIC PLCSim simulation 201 and a simulation based on the software platform .NET 202 are performed.

[0063] Here, too, a comparison can be made between the two simulation variants 201 and 202, i.e. it can be determined whether the operation of the PLCSim simulation 201 differs from the operation of the .NET simulation 202 (the difference in the results, for example, exceeds a specified limit). If there is such a discrepancy, the simulation variants 201 and 202 will not be successfully verified. Otherwise, i.e. if the operation of the simulations (substantially) matches, the verification can be verified.

[0064] Figure 3 Shown based on Figure 2 Block diagram of a test system with expanded testing capabilities.

[0065] First, the elements of the automation language (block 101) are converted or translated into a program 302 in a high-level programming language by means of a converter 301. For example, a module of the FUP programming language can be translated into a C# program.

[0066] An advantage of program 302 is that it can be subjected to known program tests and known test libraries can be used to (systematically) check program 302 for errors. Another advantage is the flexibility in which reference values ​​can be transferred to program 302. These possibilities are Figure 3 Indicated by arrow 303.

[0067] The program 302 can then continue to be used to launch a simulation, such as the .NET simulation 202. It is also advantageous that several different simulations can be launched based on the program 302.

[0068] It is also advantageous here that the domain of the automation language according to block 101 is transformed into the domain of the high-level programming language by conversion 301 and that the additional capabilities of the high-level programming language can be used flexibly for testing. This applies to the program code of program 302 and the capabilities for processing test environment 103.

[0069] Thus, during the verification of different tests, it can be determined whether the tests have the same deviations for the movement or path of the moving parts of the automation unit. The conversion to 302 programs also makes the verification of the software itself more flexible, simplified and transparent. This means that user programs can be tested or simulated on a module basis or as a complete product consisting of multiple modules.

[0070] More examples and benefits:

[0071] By validating the simulation, you can save time and money before putting the actual system into operation.

[0072] The approach proposed here simplifies engineering, testing, and enables predictive, cost-effective maintenance by enabling detection of actual system changes before (costly) damage occurs.

[0073] Although the present invention has been shown and described in detail by showing at least one embodiment, the present invention is not limited thereto and other variations can be derived therefrom by those skilled in the art without departing from the scope of the present invention.

Claims

1. A method for testing an automated application, -in, Processing data in automation languages ​​for test environments, - wherein the test environment comprises a test environment of a real system for the automation application and / or at least one simulated test environment for the automation application, - wherein at least one test of said test environment is executed.

2. The method according to claim 1, wherein: The data in the automation language includes elements or modules of the automation language provided to the test unit.

3. A method according to any one of the preceding claims, wherein: The automation language is a programming language for a programmable logic controller, in particular a programming language in accordance with or based on the standard 61131-3.

4. A method according to any one of the preceding claims, wherein: Processing data of the automation language for the test environment according to at least one of the following operations: - extracting input / output variables for the test environment; -Adjust data types; -Generate test classes based on data in the automation language.

5. A method according to any one of the preceding claims, wherein: Data of the automation language for the test environment is processed based on additional reference data.

6. The method according to claim 5, wherein: Processing the data of the automation language for the test environment based on the additional reference data according to the following operations: The data are mapped onto permissible values ​​or value ranges using the reference data, wherein in particular an adaptation can be made depending on the data type.

7. A method according to any one of the preceding claims, wherein: Validation is performed by comparing a real system of the automation application with at least one simulation of the automation application.

8. A method according to any one of the preceding claims, wherein: The validation is performed by comparing at least two simulations of the automation application with each other.

9. A method according to any one of the preceding claims, wherein: Elements of the automation language are converted into a program in a higher-level programming language, and at least one simulation of the test environment is generated or modified with the aid of the program.

10. The method according to claim 9, wherein: Test the program.

11. An apparatus for testing an automation application, comprising a processing unit, wherein: The processing unit is configured to perform the steps of the method according to any of the preceding claims.

12. A device for testing an automated application, comprising a test unit and a test environment, - wherein the test unit is configured to process data in an automation language for the test environment, -in, The test environment includes a test environment of a real system for the automation application and / or at least one simulated test environment for the automation application. - wherein the test environment is further configured to perform at least one test.

13. A computer program product which can be loaded directly into the memory of a digital computer, the computer program product comprising program code portions for executing the steps of the method according to any one of claims 1 to 10.

14. A computer-readable storage medium comprising instructions that can be implemented by a computer, wherein the instructions are suitable for causing the computer to perform the steps of the method according to any one of claims 1 to 10.

Images