Simulation-based development and testing for machine control systems

The statement goes, "The last 5% of development costs 50% of the time." There is a lot of truth here. In software development, creating a program is typically only "half the battle". The remaining time is spent testing and debugging, which is normally done fully manually. The testing effort grows in proportion to the level of complexity. And if done manually, the process is repeatedly repeated. This means a significant amount of work is lost. In contrast, with test-driven development, the tests are written in test programs and can be run again in each development phase without significantly reducing working time.

If the final 5% of development is nearly entirely made up of manual tests, which account for 50% of working time, you can only imagine how much time automated tests can save and how their traceability can produce consistently high software quality.

Is simulation necessary for machine development?

Machine simulation is still not widely used and is not seen as significant as testing. However, particularly in mechanical engineering, software development frequently begins much too late since mechanics become available far too late across the various development cycles. Using sophisticated simulation models, it would be able to begin much earlier. This decreases development pressure and may result in a shorter overall machine development process.

Figure 1: Classic Development Method and Related Problems

Figure 2: Simulation-Based Development Method

Aside from that, with a proper development infrastructure that includes features like versioning or automated tests against a simulation model, office development becomes considerably more comfortable, resulting in higher-quality software.

Classic simulation tools, such as Matlab Simulink, are accessible for simulation. Recently, however, so-called "digital twins" have been constructed, with the goal of virtually mapping the complete machine as accurately as possible. Although digital twins of future machines are visually appealing, they cannot typically be employed as a simulation model for signal-level program development. However, standard simulation models like Matlab Simulink or C/C++, combined with a real-time competent runtime environment, can meet these needs. It is ideal to include a graphical depiction of the purely logical simulation model as a machine. However, "less is more" frequently applies here. For example, a speed display on a treadmill is more logical than a graphical representation of the activity.

Hardware or Model in the Loop?

This question is difficult to answer because it is based primarily on the test strategy's aims.

A Model in the Loop (MIL) constellation develops and tests only the control system's logical functionality. Electrical signals and cables are not taken into consideration. Hardware in the Loop (HIL) additionally verifies the controller's I/O functionalities and cabling. The emphasis here is on an end-of-line test. This type of test addresses queries like "Is the machine's cabling in good working order?" or "Does the software's interaction with the mechanics work?" The key component here is a clear modular structure that can implement any type of test need using the same test methods and simulation models.

What significance does modularity have?

Modularity runs throughout all stages of development. For example, a manufacturer's machines are made up largely of mechanical segments that are frequently repeated in the same machine, but also in related devices. Simulation models, test functions, and programs should all be created in a similar modular fashion. Object orientation is, of course, the best implementation strategy here. Although there are function blocks in control development and object orientation, the distinctions between separate program sections are frequently muddled. This has a significant impact on software quality, simulation models, and testing.

Simulation models, test routines, I/O interfaces, and control logic are all available as common libraries in specific jobs on the Xentara real-time platform. A configuration file is the only means by which the needed pieces are linked in terms of time and data. Depending on the settings, all relevant situations can be inferred from here.

However, as the development and testing effort grows exponentially with increasing complexity, it is preferable to create the control logic of particular mechanical segments in modular and selective fashion. In this method, the sub-components for the various machine variations are simulated, produced, and tested individually and with a manageable amount of effort before being integrated into an individual machine at a late stage.

How may the various methods be used?

Test scenarios are frequently not implemented optimally, considerably increasing the effort required. However, due to a clear modular architecture, many efficient scenarios can be deduced from the various simulation models, test functions, and control programs.

As a runtime platform, Xentara integrates the components into a single unit and manages the processes of simulation, testing, visualization, and the system under test (SUT), which has yet to be included. Logical simulation models are combined and run as Functional Mockup Units using the Functional Mockup Interface. Together with the visual graphical simulation, they create the "digital twin". Test scripts are executed through an interface to the test language CCDL (Check Case Definition Language), which is imported, managed, and executed using Test Run Management. This allows for the creation of complicated multi-part test campaigns that can be used to test a whole computer. The test scripts are executed in the Test Operator Panel. This is multi-user capability, allowing multiple testers and engineers to collaborate on test development.

A requirements framework is an optional addition to the test environment. The system requirements are created or imported here. Links to test scripts can be used to automate verification and validation. This allows us to carefully track whether all requirements have been fully implemented. As part of the commissioning process, a human-readable acceptance document is generated, outlining all of the machine's needs.

Different test scenarios and configurations

Logical Function Tests (Model in Loop)

In this case, the control software is directly connected to the PLC's fieldbus protocol (e.g., Twincat). As a result, all inputs and outputs of a function block are checked using the previously given arrangement.

Electrical Function Test (Hardware in the Loop)

The test system does not directly meddle in the control system, but instead communicates with the "system under test" using its own electrical signals.

Test platform serves as a control platform

In this case, the machine is controlled by Xentara. This connects the test and simulation software to the control application. The sensors are not yet present, hence this configuration corresponds to a model in the loop.

Test directly on the mechanics.

In the final example, the simulation model is replaced by the actual I/O functionality. This could be an EtherCAT block with appropriate sensors or a robot-specific interface (real-time data transfer, for example).

Fig. 3: Interaction between different components in modular test setups based on a real-time convergence and runtime platform (Source: embedded ocean GmbH)

Summary and Outlook

The constant implementation of the methodologies given for simulation-supported development with concurrent tests enables automatic commissioning of the control system and the machine. In a slightly modified version, it also functions as an end-of-line test, with each machine automatically tested before it is handed to the client. This introduction page can only give a general overview of the many test situations. If necessary, practically any test constellation can be reproduced using a modular structure.