Modify channel mappings while system is deployed

[Tetro]

Hi,

I'm looking for an efficient way to modify channel mappings while the system def is deployed and system is running. It may not be possible to change "Mappings" per se, but there might be a way to achieve the same end goal with a custom device or a model. I'm looking for insights, opinions, etc.

For more context, I'm putting together a HIL station that will handle digital, analog and discrete parameters, in a systems integration lab with multiple UUTs. UUTs cross-communicate via digital buses (ARINC429, but that's irrelevant to that discussion).

The test station can be set to the following modes for any given data bus:

1. Hardware passthrough mode (real UUT transmitting to real UUT). In that mode, the transmit bus from the transmitting unit is hardwired to the receive bus on the receiving units.

2. Software passthrough mode (real UUT transmitting to real UUT, but through the controller: In that mode, the transmit bus from the transmitting unit is acquired by the controller on a receive port, and the controller re-emits all data on the bus as is or modified via transmit port. The "data" is in fact composed of hundreds of parameters per bus.

3. Override mode (user sending static or sequenced data to a real UUT): In that mode, the user manually sets parameter values or uses sequences, and that data is being output and transmitted to the receiving units. In that case, the transmitting UUT is simply left offline.

4. Simulation mode (data generated by flight models sent to real UUT): In that mode, a flight model generates data that is transmitted to the receiving units. In that case, the transmitting UUT is offline.

As you can see, for a single transmit data bus, transmitting a large set of output parameters, the data source will change based on the test case or user needs.

Say I have an output parameter, GPS_Coordinate_Transmit, that may come from different sources based on user selection: (1) GPS_Coordinate_UUT, (2) GPS_Coordinate_Override, (3) GPS_Coordinate_Simulation. How can I change the mapping from any of those sources to GPS_Coordinate_Transmit, at runtime? Also, whatever is the most efficient solution, is it scalable to 6000-7000 transmit parameters? My first idea was to use a model with a simple switching mechanism (a Case structure) that would be replicated for each parameter requiring switching, but is that solution scalable to so many parameters?

Thoughts?

[thumble · Accepted solution]

hello,

your solution is the simplest way to archive that. In our case we used a custom device because we wanted to copy back the current values from model inputs to the inputs coming from HMI (to avoid spikes when switching to HMI side).

Anyway, the drawback is the needed number of channels: in your case 7000 inputs, 7000 outputs, 2 * 7000 inputs (I think the case 2 & 3 are the same) to your switching device + 7000 outputs from it, and 7000 i/o's form models: the project ends with about 50,000 channels. We've never reached this level (max 5000 to10,000 I guess).

If I were you, I would study the possibility to spread the system over several nodes or to switch the raw data (1 full label per channel or, by merging, up to 2 raw payloads in one channel) but you'll need to encode/decode data in your models and at HMI level, or ?.

Good luck

[Tetro]

Hi,

I appreciate your feedback.

I'm wondering what would be the maximum number of channels that VeriStand can handle. Is that hardcoded in VeriStand's code? If anyone has any insight on this... Otherwise, this is something that we can spend some time testing out before defining our final architecture: just generating a bunch of dummy channels and see if we're getting close to any limitation.

As an hybrid solution, we could each time regenerate the system definition file based on the exact user need, but that comes with its own complexity and removes the "on the fly" flexibility.

I'll repost here if I get to test different scenarios.

Thanks.

[thumble]

It's not only the number of channels but the load induced by IO's and buses. About 10 years ago we built a part of an iron bird for only the primary actuator sub-system and we had to split it over a tenth of real-time nodes because of that. The heaviest ones had to deal with "only" 6 buses to emulate 2 LRU and their hardware environment in HIL & SIL. Today with the performance improvements, maybe could we have only a half dozen but not less I fear. In this project the error injection and bus override is managed in the model and limited to a maximum number of simultaneous faulted channels.

[Tetro]

I did some testing yesterday, here's what I found.

I was able to create 8000 user channels to represent the override parameters that the user may use as one of the options. No issue creating the parameters, and no issue deploying the system. Now, I understand that doesn't mean a whole lot, as I have to take into account other processes that take up processing power and memory.

Then I created a virtual switch model to switch between data sources (LRU, override, simulation, etc) for my output parameters. I was able to create 8000 models, but the system wouldn't deploy. I wish I remembered the error it threw.

As you indicate, I will have to select the parameters I want to have the option to fault before I create the system definition file. That's only a limited number of parameters, which is fine. The idea is to be able to seamlessly generate system definition files based on the user's needs, in a rather dynamic way.

[SR25]

Hi thumble,
Could you describe your solution (below) more in detail? 

"In our case we used a custom device because we wanted to copy back the current values from model inputs to the inputs coming from HMI (to avoid spikes when switching to HMI side)."

I would like to have a switch, when switch ON, the values from the model should control signals in the HMI/GUI, when value is changed it should be visible in the HMI/GUI. In case of switch OFF the signals should be controlled by the HMI/GUI and not by the model.

[Tetro]

Hey SR25,

I'm perplexed by the statement "I would like to have a switch, when switch ON, the values from the model should control signals in the HMI/GUI".

In our case, the GUI is just what it should be, i.e. a user interface. It reflects the values of certain parameters, and allows the user to change certain parameter values. However, the parameters don't "live" on the user interface, they live in the real-time engine.

We set up our system such that virtually all processing, switching, faulting, logging (and the list goes on) happen on the real-time target. This is accomplished by the VeriStand Engine. The user interface is built in LabVIEW, and allows the user to interface with the VS Engine, in a non-RT way.

Here's how we set up our switch models:

For any parameter you'd like to switch, you have a "Mode Switch" parameter (enum), and then possible input parameters. In the case above, the DisplayValue may take on the value of UserValue (from the GUI), FlightSim or AircraftParam. The parameter that is being passed through the case structure will depend on the value of ModeSelect. In your case, the ModeSwitch could be a simple "ON/OFF".

[SR25]

Thanks for helping out! Sorry, I'm quite new to veristand and labview.

Just to be clear, what I want is to change the value of, for example, a user channel (used in veristand GUI) with an external signal and to change the value of the same user channel from the veristand GUI itself, with below conditions.
Lets say that i have a "enable_control" switch to decide if "external_signal" should change the value of "signal". See illustration below.

* If "enable_control" is OFF, "external_signal" should not change the value of "signal" (possible to manually change the value of "signal" in GUI)
* If "enable_control" is ON and "external signal" is 5, "signal" should automatically change to 5 (not possible to manually change the value of "signal" in GUI)