A quick update regarding DDS-based fault tolerance mechanisms. Recently, we’ve published a blog post about a ROS2/DDS system leveraging a lock-step safety core Cortex-M7 to perform fail-over and takeover operations using QoS policies with RTI Connext DDS Micro. These DDS-based safety mechanisms do not require any broker or agent, which is necessary in other protocols such as DDS-XRCE, on an unsafe performance core. Hence, the architecture does not have a single point of failure that is hard to resolve in a safety argument. A key finding from this experiment for us was that a safety core (microcontroller) subset of the DDS protocol is sufficient for building various safety mechanisms. @AKampmann, perhaps, this information is interesting to you as well in the context of your embeddedRTPS project. For those who are curious about the background of this work at NXP, we’ve also published a Roly-poly project excerpt at the System Architecture Study Group website here.
Thank you for sharing, this is very interesting. Do you have any more resources/presentations/publications related to the project mentioned at the end?
Regarding embeddedRTPS: we have a pull request for the implementation of ownership QoS that will be integrated soon. From my understanding the other required QoS would be deadline and liveliness. We assess the liveliness of remote participants, but probably not conforming to standard yet. My impression is that not too much is missing to do this with embeddedRTPS as well. Would be interesting to replicate this in the future.
Hi @AKampmann, other publications from our Roly-poly project, hopefully, relevant for this channel and you include: a fault injection framework, a Distributed Safety Mechanism (DSM) for automated driving and a formal verification exercise of the DSM. The latter paper in a modified form is accepted for publication at the SAE Journal for Connected and Automated Vehicles in 2022. Most of this work is based on middleware stacks and often ROS is used for the experiments.
I think you’re right and the embeddedRTPS will have the right QoS policies to repeat our experiments after the addition of OWNERSHIP and OWNERSHIP_STRENGTH. Good luck! 
Great, thank you for sharing these!
Some update w.r.t. text/VCS based requirement management: 2 years ago the safety working group experimented with doorstop. Since 2020 there is an alternative to Doorstop which is called StrictDoc. Probably someone is interested in playing around again… I’ve written an intro blog post about StrictDoc on Medium which might help people to getting started.