Is there any implementation of Index Vector (Multiport Switch) for Virtual Buses?

Question

Piotr Kluczek 2022-1-18

0
链接

此问题的直接链接

https://ww2.mathworks.cn/matlabcentral/answers/1631335-is-there-any-implementation-of-index-vector-multiport-switch-for-virtual-buses

Motivation:

I am testing the MUT using output from a model. But some test scenarios need changing some signals. I do not want to handle all signals by the Test Sequence, because they are many. And various scenarios will touch different sets of signals.

Problem:

The idea is that Test Sequence provides a Bus of (initialized) signals and Bus of boolean flags (inheriting the structure - same names etc.) to the Index Vector (Multiport Switch) so that it selects desired data:

Unfortunately, this does not work and I did not find anything that would work well with buses. I also tried with the selectorBus defined as a vector, but also no success.

My Ideas:

I tried to implement this by myself and came up with 2 ideas:

Not scalable one, notice that some signals share the same data type and size so I can use Bus to Vector block to make it a bit more readable but they are still very many:
Scalable but Bus is Nonvirtual - Causing algebraic loop in feedback. I implemented such behavior via MATLAB Function block:

function replaced = structElemReplace(select, base, overwriter)
fn = fieldnames(select);
replaced = base;
for ind = 1:length(fn)
    if isa(replaced.(fn{ind}),'struct') % Intentional recursion, one can nest structures infinitely
        replaced.(fn{ind}) = ...
            structElemReplace(select.(fn{ind}), base.(fn{ind}), overwriter.(fn{ind}));
    else        
        replaced.(fn{ind})(select.(fn{ind})) = overwriter.(fn{ind})(select.(fn{ind}));
    end
end
end

Unfortunately this does not alow me to get back the signal in the feedback manner:

Thats because of algebraic loop that occurs when MATLAB Function forces Nonvirtuality (which I understand - after all I could mix everything here so algebraic loop could really occur). But in my case it is just rerouting, so that 'otherSignal' is not in the loop with itself in the end. At least that is not the intention.

Now I ended up with a solution for the algebraic loop but it is rather ugly, and just moves the problem to the models and slightly reduces it since models actually use much less signals than the whole test: