School:Very Small Information Systems/Research
Rup.inf(Rasmus): One thing to mention/discuss is the potential to use the embedded controllers for soft-real time tasks along the hard-real time tasks. Systems like JOP or JStamp represent fairly powerful processors and in the simplest case they run one control thread with WCET<<T (worst-case-execution-time much less than the period). In traditional real-time systems the designer would select the cheapest processor possible, but even so (and particularly for powerful 32 bit Java processors) there will be a large unused capacity. But the processor might be useful for other things in its vicinity such as measuring a number of temperature inputs and communicating these values across a UDP network or other non-mission-critical issues. Such soft-real-time tasks can occasionally return false from the waitForNextPeriod as they take longer than the allotted slot, but it would not matter. The Ravenscar profile on JStamp does not return true/false if the period is exceeded so that could not be used in this regard. In smart sensors, which might use some learning algorithm, it can be an advantage to get access to excess CPU power to continuously enhance the underlying model. The model might be use in the control loop. This could be achieved by assigning the lowest priority to this utility-thread (soft-real-time) such that the rest of the threads can preempt it and the hard-real time part of the system remains schedulable. Perhaps it could be an idea to discuss these things along the other issues. Perhaps the constructor of a thread can state if the thread is hard-real time or soft-real time. In the latter case the system would not see itself as failed if deadlines were broken. The real time garbage collection also needs to accommodate missed deadlines as a legal construct.