Design By Contract

[fkromer]

Is it planned to add "Design By Contract" functionality to ROS2?

On the node level the following considerations come into mind (impact of DbC on timing):

• node is topic publisher
  • (min./max. "guaranteed" topic publish rate)
  • min./max. "guaranteed" topic message type values
• node is topic subscriber
  • (min./max. expected topic reception rate)
  • min./max. expected topic message type values
• node is service server
  • min./max. service request message type values
  • (min. "guaranteed" service response time)
  • min./max. "guaranteed" service response message type values
• node is service client
  • min./max. service
• node is action server
  • (max. feedback transmission delay after goal request has been received)
  • (max. result transmission delay after goal request has been received)
  • min./max. "guaranteed" action goal message type values
  • min./max. "guaranteed" action feedback message type values
  • min./max. "guaranteed" action result message type values

[wjwwood]

Not that I'm aware of. We've discussed having a "node IDL" where you could define what the topics and their types ought to be separately from the code. This could be used to verify the system you have assembled actually should communicate with one another. But I don't think we have thought to include qualitative things like publish rates.

I'm not sure what the reaction to a topic being too fast or slow should be, a warning, an error, a diagnostics notice?

[fkromer]

I do not really know about IDLs. Is there an article about the concept somewhere in the wiki or in a website article? Would the "node IDL" address services and actions as well? How could this be used to verify a system in detail?

As in usual sw integration testing including qualitative things like publish rates would only allow to make some rough estimate about overall system dynamics and should not be considered as testing I guess. Assuming the verification overhead would have "neglect able" impact on the dynamic overall system behavior it could be helpful during node integration because verification would be faster, easier and more probable than with rostest tests.

Assertions for precondition checking, invariant (unwanted side effect) checking and postcondition checking are usually enabled just in debug builds and disabled in release builds (due to the impact on performance). Failing checks are considered as actual bug when they are "internal" to a component or an whole application during development. However if a component is "public" exceptions are usually used instead at the API level because failing checks are considered miss-use then which can potentially be handled by higher level application code.

[wjwwood]

I do not really know about IDLs

IDL is just a generic term (in this case) which means a language used to describe an interface. In this case the interface of Node, which might include things like parameters, topics, actions, services, etc...

Is there an article about the concept somewhere in the wiki or in a website article?

It's not specific to ROS or our stuff here, but:

https://en.wikipedia.org/wiki/Interface_description_language

How could this be used to verify a system in detail?

If you knew, based on the IDL of two packages A and B, that A published to chatter and B subscribed to chatter then you could infer that they talk to each other without running them.

[wjwwood]

I don't think we have any plans to pursue this in the short term. But I'm sure it's a topic others might be interested in discussing. It would be worth talking about it in the context of ROS 1 as well since I don't think there is anything ROS 2 specific about this idea, though we might have a chance to make it easier if we can identify what in ROS 1 is lacking to make it easier to do.

Feel free to continue the discussion here, but I'd recommend moving it to https://discourse.ros.org instead. To that end I'll close this for now, but it can be commented on or reopened in the future if needed.

[fkromer]

... In this case the interface of Node, which might include things like parameters, topics, actions, services, etc...

... If you knew, based on the IDL of two packages A and B, that A published to chatter and B subscribed to chatter then you could infer that they talk to each other without running them.

That means that an IDL would allow static code analysis by means of verifying the "static" behaviour of node interfaces.

However "Design By Contract" implementations target at checks during system runtime and addresses "dynamic" behaviour as well.

I don't think we have any plans to pursue this in the short term. But I'm sure it's a topic others might be interested in discussing. It would be worth talking about it in the context of ROS 1 as well since I don't think there is anything ROS 2 specific about this idea, though we might have a chance to make it easier if we can identify what in ROS 1 is lacking to make it easier to do.

I would love to have DbC in ROS1 as well 😉. I am sure people which want to implement high reliability, safety and/or real-time behaviour into the overall system will be interested in the topic.

Feel free to continue the discussion here, but I'd recommend moving it to https://discourse.ros.org instead. To that end I'll close this for now, but it can be commented on or reopened in the future if needed.

I will move the move/copy the issue to https://discourse.ros.org and reference it here.

[fkromer]

Design By Contract (discourse.ros.org)