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!
