HIL toolchain integration strategy

How to select an integration strategy for a HIL testbench?

In the context of embedded systems, there are two major domains: software design and electronics design. In both domains there already exists extensive set of tools and toolchains to meet every purpose within that domain. Integration of these two domains have been covered in my previous postings. Now the question is, how to select which tools to integrate and how, what is the strategy?

In electronics design and testing, most tools are graphical; schematic editors, layout editors, circuit simulators, test cases and sequencing, etc. Whereas in software development all tools are more or less text based, even inside graphical IDE: code editors, compilers, debuggers, unit test tools, integration test tools, etc. It's all about defining in textual format what is supposed to happen.

Graphical expressions are often intuitive and easy to understand. With simple tasks the productivity tends to be good. However, the expressive power of graphical presentations is more limited compared to textual expressions. With graphical tools one can only do such things where graphical elements exists. Combination, recurrence, abstraction, etc. are far more difficult with graphical presentations.

Graphical tools tends to be vendor specific, cross-combining graphical presentations from different vendors is next to impossible. I do not mean for example schematic editors exchanging schematic diagrams, but more like test tool automatically understanding your schematics diagrams.  In software development domain, mix and match different tools is business as usual and daily habit as such.

Due to that, I claim that in cross-domain HIL toolchain, it's better to select most of the tools from software side, and only use hardware specific tools where it is absolutely necessary, in interface to hardware instrumentation. Product specific test cases, test sequences, simulation models, etc. are all better to be done with tools from software domain.

Block diagram of possible development and testing toolchain.

Also the abstraction level of integration needs to be decided. Alternatives vary from very low-level primitives like measure instrument X channel Y to very high level commands like perform sweep-test function for the power supply under development. Clearly this selection affects the communication between tools, and the place where majority of test case logic is implemented.

My intuition says you should put in hardware side routines which are generic and not specific to any certain product. All product dependent test executions would be better to be collected in one place, for easy of maintenance, manageability and understandability.