[ros-users] [Discourse.ros.org] [Next Generation ROS] Design By Contract

[fkromer]

[quote="iluetkeb, post:29, topic:2405"]
While Im a big fan of automatic checking, I wonder which problem(s) this proposal tries to solve.

This is not to say there are no problems. I just think it would help the discussion a lot if we knew what people here are  interested in, in terms of outward behavior of system.
[/quote]

Initially my intention to start this thread was to discuss if and how formal specification and formal verification of ROS 2 node/nodelet interfaces by means of DbC could be applied to/implemented in ROS 2. I am interested in DbC because it has the big advantage that it could speed up the integration of ROS 2 nodes/nodelets within a system because it prevents from struggling with bugs which relation to the interface based interaction between nodes/nodelets. However I do not consider DbC as measure for formal verification in the testing context but in the debugging context instead because it can hardly be accurate enough w.r.t. timing, as you said, especially in real-time systems. (I do not know about any tracing tools for ROS which are usual tools for real-time related verification.) in the debugging context a comparably rough estimate is often sufficient. Assuming "system" means the overall sum of ROS nodes/nodelets this thread is not about "outward behavior of system" but it
 s "internal" integration only. If your system exposes interfaces in terms of ROS interfaces which interacts with another system DbC could address "outward behaviour" of the single sub-systems.

As DbC would be hard to implement in ROS 2 and it's benefits are not considered relevant enough in comparison to other quality improving measures like developing and using tools like a "ROS Simian Army" the direction of the thread turned into the direction of what tools are missing and could be helpful to verify a ROS based system. (Not in terms of verifying real-time behaviour.)

[quote="iluetkeb, post:29, topic:2405"]
The proposed contracts relate to a) rates and b) response times. From my own work, I know that rate information is necessary but not sufficient for determining whether a system can have sampling effects. I am also strongly of the opinion that rates should be a property of a system, not a component.
[/quote]

For me the proposed contracts are more about valid and invalid values/value ranges of the node/nodelet interfacess like topics.

However w.r.t. rates and response times I would consider different "classes":
1) the "incoming" rates one node/nodelet expect from other nodes to receive, the nodes/nodelets "outgoing" rates which are expected from other nodes, the response time of one node
2) the rates and response time of a component
2) the rates and response time of a system

If 1) the node/nodelets do not satisfy "rough" rate or response time requirements there is a pretty good chance that 2) the component or 3) the system will not behave like you would like it to behave as well.

[quote="iluetkeb, post:29, topic:2405"]
I dont know of much utility, but a great deal of problems, in specifying response times for a distributed system, particularly one with one very little real-time support, such as ROS or ROS2. If you really care about that, put your stuff into one process and ensure response times in the usual means, which have little do to with ROS.
[/quote]

If we care about rates and response times we are already putting nodelets into a single process if this is possible. (If nodes are distributed over different machines I do not know about any way to improve rates and response times anyway.)





---
[Visit Topic](https://discourse.ros.org/t/design-by-contract/2405/30) or reply to this email to respond.