Port type safety enforcement

[pavel.kirienko]

@dagar

I’m not sure I see that, in many of the use cases today there’s already the expectation of supporting multiple devices on the same bus (airspeed, GPS, ESCs, etc), and supporting this is obviously aligned with their interests of selling more units.

I think your position is self-contradictory, look:

• One implication is that by adding recommended non-fixed subject-IDs, we significantly simplify the system configuration, because a new device can be integrated into the system by merely connecting it to the bus without the need to change the subject-IDs.

• The other implication is that configurations where different subject-IDs will be required (like multiple devices of the same kind) are common, so vendors will avoid hard-coding the IDs. Yet, this implies that predefined IDs will typically need to be changed anyway, which nullifies the advantages enabled by the first point.

If I read you right and the statements are, indeed, mutually exclusive, we will end up with either:

• Hard-coded IDs will emerge at least for some device types. This outcome has the potential to kill UAVCAN v1.
• Predefined subject-IDs will not significantly improve the experience for an average user.

One way forward is just to table this problem until later. We move on to define some initial draft of the message set and then, having that as a working MVP, think about how to improve the life of a regular integrator. As I said earlier, the complexity of manually assigning the subject-IDs is being seriously exaggerated. Once we have some minimal user-friendly GUI for that implemented (either in Yukon or integrated into QGC/MP/whatever), it should no longer be perceived as a problem. That GUI, by the way, will be necessary regardless of whether there are predefined subject-IDs or not.

@tridge

I really don’t like relying on register lookups for type safety. One of the issues I see with it is that an entity observing the traffic on the bus may not be able to decode the published data correctly. This causes several problems:

This is a different topic though. We were mostly talking about type safety enforcement during regular operation, while your points are mostly focused on network analysis rather than the normal operation of the vehicle. We will talk about this too, but if we have reached a consensus on the previously raised questions (e.g., that it is feasible to use register lookups for type checking by the autopilot), it should be made clear.

A correctly configured entity is always able to decode the published data correctly. The problem is then to find robust means of configuring said entity.

Your approach is focused on changing the protocol by re-introducing the same defective architecture as in v0 that we removed from v1: using type ID to specify the semantics of the data. This approach is incompatible with modern paradigms of designing information systems, as I wrote at length in The Guide.

I just want to steer this conversation away from any dead-ends to save us all time: fixed port-IDs are not going to happen, because it is not supported by UAVCAN v1, and because architectures built on that are fundamentally flawed. We are not going to change the protocol, it is not what this SIG is about.

Note that Daniel is not speaking about fixed port-IDs. His suggestion was to link pre-defined ID ranges with specific subjects, not data types, if you follow the difference. His proposal is to basically add a table that says, for instance, that outside air temperature is reported on subjects from X to Y, and their types are uavcan.si.sample.temperature.Scalar.1.0. Then there might be some other group of subjects, say, engine temperature goes on subjects Y to Z, and they are probably to be of the same type.

The idea of defining a separate data type to represent one particular specialization of the same underlying process or state is inadmissible because it doesn’t scale and it simply goes against the modern knowledge of how to build a distributed system. This is why in UAVCAN v1, unlike v0, you don’t just define a data type for outside air temperature and then a separate one for engine temperature next to it.

The case of removing sensor-ID fields from data type definitions may seem different but it follows from the same basic principles: a data type is defined to model a particular concept that the application deals with. To continue with the above example of temperature measurement, you just define a data type that contains temperature and that’s that. You may add variance or timestamp or whatever your application requires. If you add a sensor-ID at this point, or define a fixed subject, you are dealing with a bad case of leaky abstraction because suddenly you have to think about the architecture of the whole system whereas the initial task was to define only one particular component of it.

I heard the objection like “but the subject-ID space is so large, surely we can tolerate a few fixed IDs without ever running out of it” many times, it comes out of a misunderstanding of what the subjects are for. The problem is not that we run out of space, the problem is that they are simply not suitable for the purpose.

Going back to the logging issue: adding a fixed port-ID would help you fix the logging problem at the cost of everything else. The user who reads the log is interested in the application-level states exchanged over the network (like that temperature). The way these states are exchanged is defined by the protocol layer, which is below the application layer. When you add fixed IDs, you introduce a hard link between the layers which breaks the application’s abstractions and limits the applicability of the protocol. Making the ID configurable allows us to decouple the two layers. The mapping of subject-IDs to the application’s states/processes becomes part of the vehicle’s design (or configuration). You need to know how the vehicle is designed (or configured) to read its black box.

@tridge

it makes writing a useful packet analyser much harder as the packet analyser needs to have a UI for mapping subject IDs to particular types

Yes. From what I wrote above you now see how this is a mandatory part of UAVCAN v1 that is basically baked into the protocol: you need your subject-IDs configured if you want to do anything at all with the network.

@tridge

it means captured traces may not be able to be decoded if the trace is missing a key register lookup transaction, so a single lost packet can render the trace useless
<…>
it makes “black box” data recorders much less functional as any packet loss makes it not possible to decode the trace

The subject mapping problem is outside of the scope of the protocol. Either you obtain that information from the vehicle’s configuration (e.g., MissionPlanner would know how the subjects are configured on the flight controller, or this information may be stored in the log’s metadata) or it is punched in by the user.

@tridge

this impacts on both developers and on end users. For example, end-users commonly use the packet analyser built into MissionPlanner. They expect to be able to start that up and immediately see what is happening on the bus

In the case of real-time analysis, can’t you just query the subject-ID mapping from the flight controller directly? Otherwise, the same points apply as above.

---

To summarize, we can talk about Daniel’s proposal. I think it creates a serious existential threat to UAVCAN (not just UDRAL), but it is not fundamentally incompatible with v1.

We will not talk about fixed port-IDs. This topic was discussed on this very forum many times already and a large section of the Guide is dedicated to it.

@tridge

btw, how did we end up with such an odd scattering of fixed subject IDs and service IDs in the standard? For example, we seem to have 13 fixed subject IDs in v1.0-beta, 2 of which are deprecated. Lowest value is 7168, highest is 8184. Is there some pattern to these that I’m missing?

If I understood your question correctly, it should be answered in the README here: GitHub - OpenCyphal/public_regulated_data_types: Regulated DSDL definitions for Cyphal (standard and third-party)