I don't get the context for this paper. Normally in a mission/safety critical system you're looking to determine the worst-case latency from stimulus-response. This means you:
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?
What you have described is absolutely the reasonable and traditional approach for designing a solution for a particular critical hard real-time system.
The context is that broad serialization technology decisions for autonomous vehicles are being considered outside of the focused engineering process for specific critical systems. For example, when middleware or integration frameworks come up (often with an eye toward being imposed top-down for many systems), consideration of serialization technology and its implications for performance seems to occupy an unfortunately small portion of the analysis.
This paper attempts to send the relatively simple message that "yes, serialization tech choice matters" to decision makers for whom it may not be apparent. Also, to highlight that there's a need to pay attention to messaging performance even outside of the hard-realtime parts of an autonomous vehicle.
In retrospect, you're right that more detailed bounds analysis rather than relying on the relatively facile use of means (outside of the minimal outlier visualization in the boxplot) would have been a good addition to the paper. Thanks again!
OK, I get it now. Quite surprising that serialisation is a key performance issue. But then again, pushing signals in and out of CAN frames is also a key performance feature in regular ECUs so I guess that's a universal issue with all sensor/control/actuator systems.
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:
4 comments
[ 2.4 ms ] story [ 20.1 ms ] thread1. 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?
What you have described is absolutely the reasonable and traditional approach for designing a solution for a particular critical hard real-time system.
The context is that broad serialization technology decisions for autonomous vehicles are being considered outside of the focused engineering process for specific critical systems. For example, when middleware or integration frameworks come up (often with an eye toward being imposed top-down for many systems), consideration of serialization technology and its implications for performance seems to occupy an unfortunately small portion of the analysis.
This paper attempts to send the relatively simple message that "yes, serialization tech choice matters" to decision makers for whom it may not be apparent. Also, to highlight that there's a need to pay attention to messaging performance even outside of the hard-realtime parts of an autonomous vehicle.
In retrospect, you're right that more detailed bounds analysis rather than relying on the relatively facile use of means (outside of the minimal outlier visualization in the boxplot) would have been a good addition to the paper. Thanks again!
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:
https://www.rapitasystems.com/products/rapitime