Graphical programming, but core modules in target language

This can be done from simulation level. Some modules (seen as black box) may be implemented near the target (C/++-Functions, in Simulink the S-Functions) or with adequate functionality in the simulation tool language itself, maybe graphical or as script. Last one has some maybe necessary advantages. For example looking inside the functionality, explain it, study it to find a proper target implementation approach.

This test can be done also with abstraction of details, for example in an earlier phase of development, to find out the requirements of the application.

This is the test level only using the simulation tool. Both, the dedicated test cases and the random tests can be executed with adequate stimuli and environment simulation. Some black boxed modules don’t need to be original, only its functionality should be correct. It mains, C/++-Functions can be firstly replaced.

This test is important because it is done both with the eyes of the requirements of the application and the eyes to the internal functionality. Last one: Values and signals inside the application can be evaluated and checked against the expected behaviour. First one: Often the really requirements can be determined only with experience with the result.

The test of a component (containing some modules) is proper to define their interface, to describe their functionality. A complex application should consist of some preferably independent components. It is important to better understand an application.

The components can be reused in other applications too. Especially from this reason their interface and functionality should be well designed.

Components should be defined on graphical modelling level.

This can be done in an earlier phase as well as in the end phase to test how the modules work together in the application with several stimuli.

For this tests it is not important whether modules, which are able to see as black box, are implemented in a proper replacement in the simulation tool, or near the real target. It is a functional test, not the test with the target. If a black box fulfills its interface, it is not important how it is implemented.

But the same test cases can be used with the 2) (functionality) and with the 10) (in the target).

It is an approach which can and should also checked in 2) (functionality) as well as with 10) (in the target).

Dedicated test cases may not include all situations which can occure in practice. The test cases may incomplete. They should be completed, it problems are detected. But originally, the problems may loosing sight of it. Thats why such random tests are important.

Modules can be seen as black box. Hence its functionality should be tested independent of its usage in components or in an application.

A module can be implemented for example only with simulation tool elements, either graphical or as script, to study the functionality independent of target aspects. But if a module should fulfill specific implementation aspects, such as Hardware Adaption/Abstraction Layer usage (Hardware access) or specific Operation System access, dedicated modules can be written in C/++ and can be used as S-Function in Simulink or C/++-Functions in Modelica.

A module is often implemented with deep dependencies to target properties, it should run on the target. Hence it should be tested independently of the application under target conditions.

From a C/++-based FBlock in the graphical modeling environment the original C/++ code should be tested in the target environment. But it is of course independent of the application, in a "test bed" on target.

It is important that the C-Code is the same as in usage as S-Function. The necessary adaption of hardware accesses is tested in original in this point, the same Hardware Abstraction Layer (not the Adaption/Implementation Layer) is used in 6), in the S-Functions. Same also with the Operation System Adaption Layer.

That is the difference between 4) and 5).

This tests can be evaluate before or while testing the whole application on target (5).

Any test not on the real target in the real environment is insufficient. Only the test under original conditions can guarantee that it is ok.

It is not sufficient to argument "The functional test is succeeded, the tools to generate the target are all qualified, hence the target works". It is a self-deception. A user should only accept a solution which is tested under original conditions.

The test in the target can use environment simulations done with the simulation tool. If more real time is need, for example Simulink offers some possibilities: Running in a fast hardware platform, also implementing in a powerful FPGA environment for fast real time etc. Other tools may be adequate.

This approach is named "Processor in the loop" from view of Test with Simulation. Of course the test under real conditions uses the same target.

The test in the target can be dispersed in two views:

Only b) should be accepted as end test. But a) may be a point of interesting if effects of C/++ programming should be evaluated. For this reason the implementation of the C/++ sources to test can be done also in a PC environment with better access to internals, using a PC-based IDE (Integrated Development Environment). Really of course the machine code b) ist used to test, but this environment may be better to debug. Exactly real time may not be necessary.

With the same approaches b) can be done using several targets, maybe with the end-product processor, or with an more powerful processor which offers more test access possibilities but the same real time aspects and same hardware capabilities.