# 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:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![PetervdPerk](https://forum.opencyphal.org/letter_avatar_proxy/v4/letter/p/bbe5ce/32.png) [@PetervdPerk](https://forum.opencyphal.org/u/PetervdPerk)\
**Post date:** [August 28, 2020, 7:40am UTC](https://forum.opencyphal.org/t/ds-015-get-detailed-node-functions-capabilities/930/1 "2020-08-28T07:40:02Z")

</div>

Currently UAVCAN has a defined full node info request [430.GetInfo.1.0.uavcan](https://github.com/UAVCAN/public_regulated_data_types/blob/master/uavcan/node/430.GetInfo.1.0.uavcan) which gives standardized information about the node, but this only includes basic common information.

For DS-015 we want to know more about a node, more specifically the functionality of a node, so we know what kind data it will publish and what kind of commands we can send to it. For example we’ve got a node with GPS, mag and compass or a node with ESC and Servo controls. What would be a correct way to report such functionality?

---

<div class="post-metadata">

**Author:** ![mrpollo](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/mrpollo/32/69_2.png) [@mrpollo](https://forum.opencyphal.org/u/mrpollo)\
**Post date:** [September 1, 2020, 4:25pm UTC](https://forum.opencyphal.org/t/ds-015-get-detailed-node-functions-capabilities/930/2 "2020-09-01T16:25:58Z")

</div>

@pavel.kirienko What’s your take here?

---

<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