jjj777
Finding the WCET used to be about cycle accurate models but that's long been blown away by the complexity of real hardware. But there's quite a good bit of work on how to instrument real hardware and then pick up key subpaths measurements to assemble into a good bound. These guys have been doing this for a few years now and have a good tool:
1. Determine the worst-case execution time of the software on your system (all components, including ISRs) 2. Do scheduling analysis (e.g. construct a static cyclic schedule, use a priority preemptive scheduler and do Response Time Analysis). 3. Do scheduling analysis for the network (e.g. using CAN you can apply Response Time Analysis to get worst-case latencies). 4. Do system-wide analysis (e.g. using Holistic Scheduling) to get the end-to-end latencies. Then check these against the requirements. This is particularly important in TMR systems where you need all three channels to produce results in order for voting to take place - a late result = a serious fault condition.
So I don't get why there's this focus on average performance of this algorithm rather than looking for a deterministic algorithm with good low bounds. It also seems that the message sizes depends on the algorithm itself: that also needs to be bounded to be able to analyze the communications system to determine worst-case latencies (this is of course crucial if a static time-triggered communications bus like FlexRay is being used).
The paper mentions that Linux is used to conduct the tests. But what's the actual target platform? A microcontroller with a cyclic schedule or an RTOS with priority pre-emption? If the latter, what does the schedulability analysis look like? If the former, what does the cyclic schedule look like?
What's the communications architecture look like? Is it switch-based like AFDX? Or a CSMA/CA bus like CAN? Or a TDMA bus like FlexRay? What's the timing analysis look like for the communications?