
Safety Implications of Serialization Timing in Autonomous Vehicles [pdf] - blahblahblah1
https://polysync.io/download/polysync-safety_and_serialization.pdf
======
jjj777
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?

~~~
zackpierce
Hello, and thanks for the feedback.

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!

------
jjj777
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:

[https://www.rapitasystems.com/products/rapitime](https://www.rapitasystems.com/products/rapitime)

------
zackpierce
Primary author here, should be able to address questions that arise.

