I am working on a combined custom device and custom UI project for Veristand to set up a vibration monitoring device that will monitoring rotating machinery for gear and bearing health and trigger a shutdown if vibrations indicate a mechanical issue.
The challenge is that we'll be monitoring the system with up to 80 different accels so we'll need to perform 80 FFTs, do limit checking, and display results. We also need to edit the custom device config while operating (FFT window type, limits, logging, etc). The required display complexity and data density meant that there was no practical way to implement the UI in Veristand and we are thus implementing a fully custom UI which is receiving data from the Veristand gateway and allowing the user to view output data and change the custom device inputs as needed.
I'm still using the Veristand Workspace UI though for testing purposes. I've found that even small amounts of data on the Veristand UI consumes far more resources than the custom UI.
One observation is that I think charts are updating far too quickly in Veristand. I don't know how Veristand works internally, but I wonder if the chart is refreshing at the streaming rate, or at the streaming rate up to a limit. Human decision making bandwidth is at most 5Hz for a gauge and maybe as low as 2Hz for graph, depending on the decision that needs to be made from that data. Those are only peak bandwidth numbers which can only be held briefly. Normal human controller bandwidth is more typically 0.5 to 1 Hz when not intently concentrating on a single measurement. Numerical data on aircraft displays is often updated at only 2-5 Hz. Tapes and gauges are drawn faster, between 5 and 10Hz. The only depictions drawn faster than 10Hz is the artificial horizon which is usually drawn at 20Hz.
Additionally, I don't know how the comm loops run in the Veristand Workspace, but it would be safe to buffer all incoming data from the RT OS and have the UI poll the buffer at a reasonable rate such as 30Hz max. There is little point in polling for data at any rate faster than a screen refresh rate. Even then, the actual indicator update should be appropriate to the indicator. Namely, about 5Hz for most numerical display types.
I am used to building UIs for flight test where you can have one station monitoring 500-1000 channels with channel data rates ranging between 20 and 3000Hz. The custom UIs I create obviously make heavy use of automated limit checking and display on exception when possible, but I think that the Veristand Workspace UI could be made quite a bit more efficient.
I am wondering what others think. Has anyone had issues with high CPU load caused by the Veristand UI? I'm wondering how well it would scale.