Quoting Josh Triplett <j...@joshtriplett.org>:
http://www.osadl.org/?id=99
Yeah, a huge amount of -rt has made it into mainline Linux.
The question remains, what do we actually need?
This is a good question, and IMHO the answer is fairly straight forward.
-We need the ability to run one or two critical control algorithms at
regular intervals.
-We have to be able to guarantee that they will run on-time if they
are responsible for sampling data.
-We must guarantee that they will be completed in one control cycle.
Since the sampling is done by the sensor nodes, and the BPF / LQG / NN
/ whatever estimator will determine the state and decimate the data,
we only need to 1) be as 'on-time' as the control cycle and 2) keep up
with the data.
Our control loop could run like this:
Get data inputs (speed, position, etc.) from BPF.
Run control algo (LQR, MPC, PID, whatever)
Send outputs to the latest values.
Yield until next control cycle.
As long as this happens within the control cycle period, we win. If it
doesn't, the math that makes it work breaks down and we 'could' crash.
To make this guarantee, industry practice is to build run time metrics
that measure processor load (instant, min, max, running average) based
on idle time. As you build the control system, you watch the metrics.
I don't let systems into 1st production with more than 70% loading.
The last one I did shipped at less than 20% loading (fairly simple
system).
If the control task runs over (takes more than one cycle to complete)
we want to log the event so we can make sure we don't see it, and
recover gracefully if we ever do.
That's really all that's needed for real time control.
Thoughts? Challenges?
_______________________________________________
psas-avionics mailing list
psas-avionics@lists.psas.pdx.edu
http://lists.psas.pdx.edu/mailman/listinfo/psas-avionics
