I think that this is an important question about what the scope should be. The diagnostics system was not designed to be a safety system nor a pathway for active automated responses from other nodes. It was designed to provide a human visible status of components as well as keep track of long term logging of hardware related systems.
It is not possible to use ROS to control a robot without ROS becoming a part of the safety-system as robots have active-safety use-cases so this is a critical need.
If the diagnostic sub-system does not intend to provide diagnostics then it should be renamed to reflect its intentions and the quality-level assertion of Ok, Warn, Error should be removed to avoid confusion.
Documentation should be updated to reflect that ROS does not provide operational diagnostics.
i.e. This is a have-your-cake-and-eat-it-too scenario. We have to choose.
I don’t agree here. There are many examples of this- independent systems which control application of motor power, hardware with non-ROS based embedded code which is watchdogged, simple e-stop switches, etc.
In general, properly safety certifying software is a huge undertaking and the typical approach tends to be to just avoid it (or rather find ways to safely operate independent of the ROS based software).
Your initial assertion here is debatable. As @Chuck_Claunch replied too. But even if you take that as a given, the jump here from if ROS has to be in the system to diagnostics has to be in the critical loop too does not follow. As I said above:
Please understand that your use case is completely valid, but different than what the diagnostics system is designed for. Every different application has different levels of safety certification. You appear to have some pretty strict requirements that you’re trying to impose on this widely used widely deployed system that’s not in it’s scope.
I appreciate this doesn’t match your expectations however the naming seems quite apt for the intended scope. According to Oxford Languages used by Google the definition of diagnostic is: “Computing: a program or routine that helps a user to identify errors.” Which quite accurately aligns with the designed scope.
I’d also like to point out that renaming a mature heavily used package like this is not something to take lightly or likely productive for the ecosystem. It’s being heavily used by many packages and would cause innumerable maintainers through the entire ROS ecosystem to go through a gigantic migration with a very high cost to many people.