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.