# DS-015 Get detailed Node functions/capabilities

**URL:** <https://forum.opencyphal.org/t/ds-015-get-detailed-node-functions-capabilities/930>\
**Category:** General\
**Created:** [August 28, 2020, 7:40am UTC](https://forum.opencyphal.org/t/ds-015-get-detailed-node-functions-capabilities/930 "2020-08-28T07:40:02Z")\
**Posts on this page:** 1\
**Showing post:** 3

<div class="post-metadata">

**Author:** ![pavel.kirienko](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/pavel.kirienko/32/9_2.png) [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\
**Post date:** [September 2, 2020, 3:06pm UTC](https://forum.opencyphal.org/t/ds-015-get-detailed-node-functions-capabilities/930/3 "2020-09-02T15:06:04Z")

</div>

We need to start with the basic question: why is it helpful to know the functionality of a node beyond the set of the ports it provides?

With the currently proposed register API, one can determine whether a node has a port by its name (that is, by the final component of the register name like `uavcan.pub.mangnetic_field_strength`). Proper naming provided, this should be enough to provide some minimum degree of introspection for basic applications.

This method notably lacks the type information. It was noted a long time ago in [GUI Tool – Next Generation - #24 by pavel.kirienko](https://forum.opencyphal.org/t/gui-tool-next-generation/229/24), where a solution was proposed:

> [@GUI Tool – Next Generation](https://forum.opencyphal.org/t/gui-tool-next-generation/229/24):
>
> The [proposed] solution is to further extend the register naming conventions by adding a new name pattern: `uavcan.type.*` , where the asterisk stands for the port name – e.g., `uavcan.type.servo_angle_roll` – the value contained in the register will be the name of the data type together with the major version number, like `uavcan.si.angle.Scalar.1`.

Although the specified pattern lacks the pub/sub differentiation, so it should be factored in as well. It is not mentioned in the quoted excerpt but the register would be read-only (persistent, immutable).

Currently, it is probably out of the scope of the DS-015 MVP effort, but I expect that it will become relevant after the first version of the standard (DS-015) is released, along with a few other more advanced features.

FYI @TSC21

---

_[View the full topic](https://forum.opencyphal.org/t/ds-015-get-detailed-node-functions-capabilities/930)._