1. Field of the Invention
The present invention relates to automated testing of systems and, more particularly, to the integration of model-based testing with test execution platforms and automated testing frameworks particularly well-suited for providing thorough, automatic testing of complex mechatronic systems.
2. Description of the Related Art
Mechatronics is an engineering approach that manages the synergistic integration of mechanics, electronics, control theory and computer science within product design and manufacturing in order to develop, improve and/or optimize the functionality of the product design and/or a manufacturing process. Mechatronics is an increasingly important approach in many of today's industries that rely on extremely complex and heterogeneous subsystems in bringing a product to market or providing a service. For example, maintenance and control of a mechatronic-based production line facility that requires the monitoring of a variety of different machines (probably from different vendors), the software programs running the machines, the hardware controls of the machines, and the like.
As the scale of complexity of mechatronic systems continues to increase (which obviously increases testing costs), approaches that automate the execution, generation and reporting of test activities become increasingly important. In particular, software has become an important part of today's mechatronic systems. Indeed, expert predictions contemplate scenarios where the fraction of software-based system components will continue to increase without limitation, overtaking the place of pure mechanical systems in many industrial settings. The shift from mechanics to electronics and software presents different challenges in the verification, validation and certification of such systems.
Traditional engineering approaches, adopted specifically for a single aspect of these mechatronic systems in isolation (e.g., software testing vs. electro-mechanical control testing) tend to be inadequate or do not scale to the complexity involved in the development of these “systems of systems”. As of now, the testing of mechatronic systems is supported by a loosely-integrated combination of commercial and industry-specific solutions including hardware abstraction frameworks, test execution engines and model-based testing tools. While these approaches individually address specific issues on different levels of abstraction, they remain essentially isolated in operation, hindering their combined adoption in industrial settings.
At times, these combinations need to be integrated in a manual fashion in order to automatically develop (or derive) test scripts from a given model, which is obviously both time consuming and expensive. The various tools that do exist for automatically creating test scripts are not well-suited for the heterogeneous collection of elements forming a mechatronic system.
FIG. 1 shows a typical prior art arrangement that uses engineering personnel to manually generate test scripts 1 that are used by a conventional test execution engine 2. As mentioned above, the development of the test scripts is extremely time consuming, as well as error-prone (particularly in terms of covering every possible situation to be evaluated). The scripts must be developed in a language suitable for use with the specific type of system used for text execution engine 2. The engineering personnel must also manually develop the specific configuration 3 of the mechatronic system under test (SUT), applying this configuration 3 to an Automated Test Infrastructure (ATI) 4. As shown in FIG. 1, execution engine 2 sends a series of tests to ATI 4 and collects results for various uses, such as modifying and updating the SUT, verifying and validating the operation of the SUT, etc.
ATI 4 focuses on providing a software interface to the specific hardware devices forming the mechatronic SUT, illustrated as device abstraction layer 7 in FIG. 1, allowing test scripts to be produced for different hardware configurations. As shown in FIG. 1, ATI 4 supports strategies such as “Hardware in the Loop” (HiL) 5 and “Simulator (or Software) in the Loop” (SiL) 6, which allow testing of incomplete, embedded and mechatronic systems under different configurations. For example, a given mechatronic SUT may be “incomplete” in terms of selected hardware components not yet ready for use, allowing for a software-based simulation of these components to be added to the system and tested accordingly.
While frameworks such as that shown in FIG. 1 address some system testing issues (such as heterogeneity, external dependencies, and the like), the process still relies on engineering personnel to develop the initial test scripts, define the configuration of the mechatronic SUT, update the configuration for different environments (i.e., “deployments”) and then, possibly, update the test scripts to coordinate with the updated configurations. The need for engineering personnel to perform this manual creation of test scripts and configurations results in an arrangement that is expensive, inefficient and still prone to errors in providing verifiable results.
Thus, a need remains for an automated testing platform that is capable of handling mechatronic systems, addressing the various needs as outlined above.
USPTO Backgrounds
USPTO Backgrounds