As ROS2 seems to consider functional safety in the system design it’s probably worth checking out the thesis Design Patterns for Safety-Critical Embedded Systems. The thesis recommends SW and SW/HW design patterns based on safety integrity level (SIL) requirements. The required SIL usually depends on the domain (e.g. automotive, avionics, medical, etc.) the system is used in, application specific risk estimations, etc. . The patterns are not limited to Embedded Systems but generic and can potentially be adapted to ROS2 on different levels (source code level, node level, collection of nodes implementing a “cross-cutting” feature). The reliability of some ROS2 core components could potentially be improved. I don’t want to raise the question if and in case which ROS2 components should consider the design recommendations. However I think it could help a lot to point at this topic early to prevent from technical debt and/or “vendor” specific forking/development/maintenance of ROS2 core components which could easily be shared without conflicting with vendor specific interests.
Some things to point out:
- The HW patterns from the catalog of patterns (6.8. Catalog Structure) are not about HW only but imply/require SW considerations as well.
- The list of “high, architectural level” patterns is not exhaustive.
- The list of “low, idiomatic level” patterns is not considered at all. In the HAL-level of MCUs vendors usually provide “self-test libraries” e.g. for Cypress MCUs to implement the SW for HW-based self-check capabilities. The libraries of MCU vendors usually provide one implementation variant for e.g. the “memory self test” pattern. However, also in this layer of abstraction, there are different alternatives how to implement a single pattern.
- The level of abstraction does not always allow a strict categorization of patterns. They can sometimes be applied to different levels of abstraction.
- A single pattern or a combination of different patterns (either addressing SW or HW+SW) can lead to the same end result w.r.t. satisfying the required reliability/safety requirements. The recommendation of decision trees to support the design process (6.5. Decision Support) has been implemented as part of the thesis but which is unfortunately not publicly accessible.
@vmayoral Probably interesting for SoM (H-ROS), HRIM as well as MARA.