Hi Markus,
Creating tests that scale from MIL to HIL takes a bit of planning, so it's a good thing you're doing it from the start!
The basic principle you need to follow is that you need to create stable interfaces for the different components of your system, the same way you would separate public and private members of a class if you were doing OOP.
In VeriStand, you can express this by creating aliases, which allow you to create logical names and groupings that are independent of the implementation. You can map these aliases to the relevant inputs and outputs.
For example, during MIL, your control model could have an input called "PedalPosition" that you map to a "PedalPositionIn" alias. You could then have another model that outputs that value and map it to the "PedalPositionGenerator" alias. Then you'd connect "PedalPositionGenerator" to "PedalPositionIn" in your mapping diagram. You could then write your test sequences through Stimulus Profile Editor, the C# API, or TestStand that stimulate your control model, all of these going exclusively through the public API that your aliases have defined.
As your application evolves into HIL, your control model would be replaced with the real DUT. Now the "PedalPositionGenerator" would probably be some kind of LVDT simulator that you read through FPGA. But since you've already designed your system with clear interfaces, all you need to do is change the mapping of the aliases. Since aliases can be exported and imported with just a few clicks, you can go from one setup to another very quickly.
Hopefully this gives you a good idea of how to get started with abstracting your system and creating public interfaces that scale throughout the development process.
