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

fkromer ros.discourse at gmail.com
Sat Aug 12 10:15:13 UTC 2017

> I have often put some thought into providing such an idea over the years, but Ive never come close to putting in enough effort to actually do it. :slight_smile: Id love to see such work move forward so Im happy to see someone putting in the work!

I have my roots in the domain of embedded software development. Most languages used there like C/C++ are lacking a built-in support for "Design By Contract" (one exception is e.g. Ada) and try to compensate the lack e.g. with coding standards suggesting to define the interfaces in a "contract" like manner as part of the built-in code documentation. But in comparison with language built-in support all these measures are very weak. To get to the point... this topic is keeping me busy for quite a while :slight_smile:.

> Having said that, I think that it would be a major effort to achieve for ROS 1, but quite doable for ROS 2 because many of the things you want to establish as the contract for a data-flow-based software component can be implemented using the DDS QoS policies. It would need some thought put into how and where to specify the contracts and then how to translate that into QoS settings. On from that things get more complicated.

ROS is a new technology for me. But after reading a bit about the ROS2 design I thought the proposal for "Design By Contract" would fit better into the ROS2 design GitHub repo than into ROS1 (and discourse.ros.org) in the first place. Unfortunately I do not know enough about ROS2 to implement something reasonable on my own yet. However I am very interested in contributing code if it is ensured that it is no waste of time. (Means contributing code w.r.t. some reasonable up-front design.)

> This can be done using the DDS DEADLINE QoS policy.

I will dive deeper into DDS and QoS policy the near future.

> DDS provides facilities to be informed when a QoS policy has been violated, but how to respond to that is probably going to be very application specific. (In classical Eiffel-style DbC, the contracts are essentially asserts that raise exceptions when violated at run time.)

(In D one can decide whether to use "assert", "static assert" or "enforce" checks. "assert" checks throw an AssertError which is no Exception but an error during runtime. "static assert" checks do the same but at compile time. Both are usually enabled during debugging only.
"enforce" checks throw exceptions at runtime which which can be handled and are most suitable for public interfaces.)

> This could be done in the message IDL and an assert in the topic publish API. There has been occasional talk in ROS 2 discussions of adding allowable ranges to the IDL, but I dont think its gone anywhere. However if it is going to be node specific it would probably be better done purely in the topic publish API, with a node declaring when it sets up the publisher what allowable ranges the message can hold. This would be fine for run-time checks, but it would make it a lot harder to check contracts statically than having them in the IDL. I think that the need for a unique message definition for every node would be too prohibitive to put contracts in there, though. Other than perhaps things that everyone agrees are sensible for that particular message.

Unfortunatelly I do not know much about IDL as well right now. From a conceptional point of view the possiblility for static checking considering a single source of specification should be favored. Considering the "static" behaviour of the node interface only the IDL seems suiteable for me. What do you mean "if it is going to be node specific" exactly? In case of exotic node topic message types?

Will "dynamic" aspects like the "guaranteed" publish rate of topics is gooing to be defined in the IDL as well? If so then the IDL could be a suitable place for these kind of contract information in the first place as well. However if one thinks further about situations where the "guaranteed" publish rate shall not be constant but dependent on the node state during runtime (in common if the behavior of the node depends on its state during runtime) the IDL seems not that suitable anymore.

> Now were getting close to Eiffel-style DbC. These can be done now by putting asserts in your service callback, but what you really want is a way to notify the caller that there was a problem fulfilling the service call due to a contract violation. This would probably require extending the way services are implemented.

In case a "strict" contract check (analog to D "assert" checks throwing errors) would fail one as programmer should be notified somehow about that (e.g. logger). In case of "weak" contract checks failing (analog to D "enforce" checks throwing exceptions) the caller should be notified directly.

> The RPC over DDS specification, which was finally published in April this year and hopefully the OSRFs DDS vendors will rapidly support, does not provide any QoS policies specific to services (only ways to specify existing QoS policies on a per-interface level). Therefore ROS2 would need to decide how to deal with contract violations themselves.

I will dive deeper into DDS and QoS policy the near future.

> So the things that you are requesting are doable in ROS 2 using a combination of the DEADLINE QoS policy and adding some features to the API for specifying pre- and postconditions. I do not think it would be a huge level of work, but there would need to be a focus on how the API will work to make it clear what is happening, and making sure that the performance is both minimal and zero-able (i.e. all checks can be turned off).

I consider the possibility to "disable" performance overhead essential as well. The possibility to keep performance overhead minimal would depend on the communicated data type to a great extend I guess. I would love to contribute.

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

More information about the ros-users mailing list