Data type regulation policy and membership fees

@lorenz.meier predicts that the current set of regulated data type management policies is unsustainable. In his view, the current approach where we combat fragmentation of interfaces used in the UAVCAN ecosystem by encouraging vendors to use and extend existing solutions instead of defining their own is likely to fail because independent vendors are inherently prone to short-sighted behaviors. Fundamentally, the minimization of fragmentation is in the best interest of users and integrators of UAVCAN equipment. Market forces should drive the appropriate response from vendors, but the resulting indirection requires long-term reasoning which they lack, which results in a net loss for all involved parties. According to Lorenz, we should search for a solution that allows participants of the ecosystem to align their interests through a shorter chain of inferences.

The above is my interpretation; I am happy to be corrected if my channeling of his view is distorted.

The intention of the current policies is to bootstrap a well-formalized process of maintaining vendor-agnostic regulated interfaces for common tasks (such as commonly used types of sensors or actuators). Parallels can be found in the standard CANOpen profiles, standard USB classes, Bluetooth profiles, and certain commonly used data types defined in ROS. The UAVCAN team lacks the expertise and resources necessary to provide a workable set of standard interfaces for common use cases at this point. It also lacks the necessary political leverage to solicit required inputs from existing adopters. Our solution to the problem is an incremental process, where we set out rules that should enable us to increase the involvement of vendors in the data type regulation process gradually, with the long-term aim to eventually turn the resulting set of involved parties into a well-regulated consortium that will be capable enough to define and maintain the aforementioned set of vendor-agnostic regulated interfaces.

We recognize that the incremental process runs the risk of fragmentation, especially considering that its success is very sensitive to the performance of the UAVCAN maintainers. However, we do not have a better solution at the moment.

It has been proposed to implement a formal compliance assessment process as a way to minimize the aforementioned risk. The compliance assessment process is, essentially, a direct re-implementation of the USB-IF Logo License policy: UAVCAN vendors who are interested in ensuring that their equipment is strictly compliant to the letter of the standard submit their products to compliance testing for a fee, obtaining the right to use a recognizable feature (such as a particular logo) with the product. It is predicted that the increased involvement of vendors will reduce the risk of fragmentation.

The crucial aspect of the logo policy is that it in no way infringes upon the open nature of the standard, remaining a completely optional feature only for the interested members of the ecosystem. In order to underline its optionality, the logo policy may need to be implemented as an addition outside of the main body of the standard.

This post is to highlight the following issues that may require discussion:

  • Does the current regulated namespace management policy require updates before it is deployed in UAVCAN v1?

  • Are there any concrete proposals for the implementation of the compliance testing process and the related fees and legal issues?

FYI @anton.krol

1 Like

I believe the intent of our documented plans are compatible with @lorenz.meier 's suggestions if they are incomplete. I suspected that a UAVCAN “special interest group” (to borrow the term from Bluetooth) would be desirable given the existence of any speculative manufacturing. As we are already seeing this with v0 it seems time to consider the formality.

First off, I think we can tighten our specification to reduce confusion and simplify definitions if we change to this matrix:

regulated unregulated
public managed illegal
private n/a unmanaged but supported by the specification

The difference here is that we no longer endorse public unregulated types. If you want to have your own types you have to keep them to yourself or you have to regulate them. Of course we can’t legally enforce this but by stating that it is not allowed per the specification we can, hopefully, influence more manufacturers to work with the UAVCAN community to define public, regulated types.

Now, what this means is the onus is on us to proactively define and publish public, regulated types to make v1 usable. This can happen in a number of ways:

  1. Informal, community driven – Where we use only our ownership of and our maintenance of the specification as the lever to regulate public types. We proactively define a first set of profiles (e.g. UAV, satellite, rover, etc) and use the community process to ratify the types contained within. Publication is simply documentation on and DSDL on Github.

  2. Formal, organization driven – Here we would setup a legal entity that would own the UAVCAN trademark and would license rights to it based on compliance testing against a test suite. In this scheme we require members of the organization to define, ratify, and maintain public profiles. The organization would only regulate the UAVCAN trademark, legally, leaving the core specification’s licensing unmodified and also making that organization’s activities orthogonal to the working group driving standardization of the core specification.

  3. Formal, specification driven – In this scheme we would create higher-layer specifications on top of the core specification to define public, regulated application profiles. The same working group responsible for standardizing the core specification would also publish and maintain these higher-layer specifications. The application profile specifications would be licensed the same as the core and there would be no formal membership required to participate in their definition or use the final result.

I am strongly opposed to a fourth option of publishing public, regulated types in the core specification beyond the highly generic types we currently propose for v1. I think doing so was a decided weakness with v0 that we have properly cleaned up in v1.

I think this issue has many parallels with the rejected alternatives of fixed port-ID management policies discussed in the thread On standards and regulation. Vendors will want their own types because other industries show that even a well-regulated and expertful consortium is unlikely to foresee all sensible use cases. I expect that such conservative policies may stifle the development of new products and applications based on UAVCAN, so I suggest keeping the current approach where public unregulated types are permitted but discouraged.

I agree.

“I don’t think the name of a namespace could prevent other companies from using it in their systems or products.” I think you are mistaken. A simple example. I need the types of RPM, MOTOR_TYPE, MOTOR_NUM_POLE_PAIRS, MOTOR_Rr, MOTOR_Rs, MOTOR_Ls_d, MOTOR_Ls_q, MOTOR_RATED_FLUX, MOTOR_MAGNETIZING_CURRENT, MOTOR_RES_EST_CURRENT, MOTOR_IND_EST_CURRENT, MOTOR_MAX_CURRENT, MOTOR_FLUX_EST_FREQ_Hz and so on. This is necessary for the normal operation of the FOC controllers. Do you think that a company producing controllers will use data types of another company? :frowning: Never.

Could you please elaborate why do you believe that this might be an obstacle?

I do not know more than one manager who would allow to use the name of another company in a commercial product. This may result in legal consequences. For example, who is the company ZUBAX and why can you trust her? :slight_smile: As a result, each company will duplicate types, etc. Do you want to adjust types for companies? This is a dead end. Want a ZUBAX or another company? But, this should be in the examples or test. Everything should be as abstract as possible.

Thank you for the elaboration. We have addressed the legal aspects by distributing all public regulated data types under the MIT license, which permits free reuse. Hence, a vendor releasing a data type into the public regulated set makes it freely available to other vendors. Do you think there might be other issues?

data types will be repeated. No one will compete with types where another company type. On this, you can close the topic about company type. Because personally, I will never use the type of ZUBAX or so. Back to the question. In which space should the motor parameters be located? #<_company>.motor.< option>?

Sorry, I still don’t understand why this would be a problem. Unless I am missing something, there are no undesirable legal implications. Are you concerned about marketing/image issues? If this is the case, perhaps your mental model of a data type definition requires adjustment.

The purpose of a regulated data type definition is to provide an abstract common-ground interface for a typical function available on the network. The name of the namespace where the data type is located does not affect its generality. You can think about it as a software API that provides access to well-defined functionality in a generic and abstract way (consider the list of common Java APIs provided by many different vendors, or the contributed Python packages included in its standard library). Vendors are expected to make use of regulated namespaces just like they make use of third-party libraries, tools, operating systems, and so on.

My? :slight_smile: I conducted a survey among staff and students. No one understands why you need to use types of other firms. The specification is just what is needed to create more abstract concepts. I repeat. Repetition of types with this approach is inevitable. in Java, Python. It will be the same here. If you limit the number of developers, you can immediately close this project. Need an abstraction.

1 Like

Another interesting point. There is a metric system SI. What to do with England and America? Arrange a race which company will make new types for itself? :slight_smile:

1 Like

Vendors will be able to create and distribute their own data types without limitations, just like it was in UAVCAN v0 (there are certain rules governing the usage of fixed port-ID though, but they do not affect types themselves). I think this point might have been lost in the above discussion.

This topic is focused on regulated data types, not just any data types. Think about them as standard USB classes – it is really a good analogy. Any vendor of USB equipment can create their own custom USB interface, but they can’t affect the definition of standard classes. To do the latter, one has to bring their proposals into the committee that maintains the USB specifications. Same thing is currently proposed for UAVCAN.

As a vendor, you can define an distribute your own data types as you see fit (mind the fixed port-ID assignment rules though), but if you want them included in the regulated set, you have to synchronize with us, the maintainers.

SI is an international system, so no special cases are needed.

I think there is truth in both views here in relation to using another company types.

While many companies will have no problem using a type within the namespace of very well known companies, I don’t think it is realistic to expect they will use types from the namespace of unknown or direct competitors.

Why do we need a direct relation to a name? Couldn’t the type ID be related just to the contents? Then namespaces will be just conventions to group associated abstract types. Even if company B uses a type originally created by company A, it will not matter because it can call it whatever it wants, and still be compatible with any other type with the same contents.

Is there any special reason this can’t or shouldn’t be done?

I see regulated types as just a way of specifying well known types (e.g. a timestamp), associations between types and protocols (e.g. types used in a file transfer protocol) and define protocol-specific semantics (e.g. this timestamp for this version of the protocol must have some minimum resolution to be valid).

Perhaps the use of private data types although creates repetition, it could aim to create a sense of customization in the specific application that a particular company is building.

The reason we went with vendor-named namespaces is because this naming policy seemed clear and self-explanatory. I personally find the concerns expressed here so far insubstantial, but we are certainly open to new ideas. Could you (or anybody who’s reading this), perhaps, formulate a different naming policy proposal? You may find the following discussion relevant:

I have no problems with whatever namespace policy is decided, including having private company namespaces.
My point was that if we decoupled the actual structure type from the name (by, e.g., hashing the structure without any names or comments) then there would be no disadvantage in having private namespaces which were just a copy of other namespaces.
Names in the namespace would end as just a mapping to an abstract structure, because even if they were defined by different DSDL (with different field names, but same structure), the serialiser/deserialiser would be the same whatever the namespace, so we would end up saving on generated code and be able to have different companies having their own names for structures which would be compatible between them.
As a further advantage, after a used structure proves to be well established and used by everyone, it can move to a regulated uavcan namespace and everything would still work because it is only a “metadata” change.

Sure. What you are describing has been available in v1.0 since day one. You can find the details in the Specification:

Sorry, I did read an early draft of the 1.0 specification but seems I forgot most of it by now
We are using v0 on some of our internal projects. Have been waiting for some free time to start migrating things to 1.0 but lots of other more important things to do…

1 Like

At the dev call yesterday we’ve been discussing the problem of data type regulation again with @scottdixon, @TSC21, and @dagar.

The conversation was revived due to the ongoing work on the standard UAV profile spearheaded by the PX4 team. Their objective is to define a reusable vendor-agnostic set of well-defined standard data types and protocols on top of UAVCAN v1.0, as we intended:

Our challenge here is to ensure that the UAV profile can be integrated sensibly into the larger UAVCAN (U for uncomplicated) ecosystem with the following objectives met:

  • UAVCAN-enabled hardware and software from different vendors are interoperable. This implies that the standard types are discoverable and vendors are not unnecessarily incentivized to rely on custom (unregulated) definitions.

  • The functionality addressed by regulated data type definitions is not unnecessarily replicated. It is acceptable and natural for a newer definition to obsolete its previous revision, but it is undesirable for the regulated set to contain multiple definitions addressing the same use case in incompatible ways.

  • Where appropriate and sensible, data type definitions are reusable across application domains. For example, manned electric aircraft and heavy UAVs typically leverage similar propulsion systems and power management hardware; likewise, the sensor suites of a car and an autonomous UAV may overlap. Cross-domain reusability would be beneficial for the larger UAVCAN ecosystem.

In the search for a sustainable data type regulation policy, we came up with the following options to organize the public regulated data type repository.

Segregation by owner

There will be one namespace under regulated per vendor/project. This proposal is currently in effect and it’s been discussed above in this thread (although, naturally, it is not final, otherwise we wouldn’t be having this discussion here). I consider it the most viable among the alternatives.

Under this model, the data types that are being worked on by the PX4 team would be published under the namespace regulated.px4 or similar. Having PX4 in the name does not imply that the types are specific to that project only; rather, it implies that they are the original author and initiator of the design.

Shall it be necessary to borrow definitions into an adjacent namespace despite everything, it should be possible to do by symlinking types or entire namespaces across directories. Remember that neither the name nor location of a type affects its wire compatibility.

Obviously, licensing issues have been considered: all regulated data types are released under the MIT license so reuse is possible with virtually no restrictions.

I would like to solicit opinions from the ArduPilot camp: @tridge @jani.hirvinen.

Segregation by application domain

There will be one namespace under regulated per application domain. For example, the types developed by PX4 would go under regulated.uav.

This arrangement creates obvious cross-domain reuse issues. To some extent, they may be addressed by symlinking, but the type discoverability issues persist.

Segregation by generation or some other abstract property

This is idea is new and rough. At the call, it’s been proposed to shard the regulated namespace by a more abstract property. Assuming that we failed to come up with a well-reasoned solution now, a namespace named after no particular entity could be chosen to contain all definitions we find relevant at the moment; for example, regulated.a. If this approach survived the initial trials, its successors could continue the trend with regulated.b, regulated.c, etc.

This approach risks making the data type set unmanageable in the long run.

No segregation

A flat structure like in ROS. For example, a particular BMS status message would go under (currently, it’s under

This is unlikely to work because we lack the required expertise.

There is one more scheme to consider (this is offered only to enhance the argument not as a proposal)

Segregation by device class

Similar to USB-IF classes, we could segregate interfaces by the hardware design goals. This is similar to the no segregation proposal but is flatter and requires each class to be developed by expert working groups with type evolution occurring at the device-class level instead of within an ecosystem as a whole. This means we would not accept a blanket specification for “UAVs” into the regulated set but would instead accept standardization for specific device classes. A drone system could then standardize on a set of regulated types but such a grouping of supported device classes would be a higher-level standard on top of the lower-level regulated types. Such leveling of class and group would naturally allow cross-domain sharing of types.

For example regulated.class.bms_light would be for a class of battery management devices designed for, relatively, low voltage (i.e. < 60v) and lightweight vehicles. This allows for a class of regulated.class.bms_heavy to exist for battery management devices designed for high voltage and/or heavier-weight vehicles like cars and trucks. In this scheme we are careful to describe the device class abstractly before assigning a class under which the working group can standardize specific types. The design goals for the hardware class are described by the type to ensure the proper trade-offs are made when designing types. Now add an example like regulated.class.esc_rotor and regulated.class.esc_wheel (to allow different interfaces for esc’s where microsecond responsiveness to control input is critical versus esc’s where power efficiency is paramount) and a UAV group would start with “The UAV profile supports the following UAVCAN device classes: bms_light, esc_rotor. …”. This allows manufacturers to choose appropriate interfaces based on the hardware they are developing and system integrators to limit the device classes their primary controllers have to support. As with USB, we would expect more powerful and complex systems to support greater numbers of UAVCAN device classes and smaller, more specialized systems to support fewer.

Base Classes

One other tool to consider is to utilize UAVCAN 1.0’s support for message extensions by defining generic base classes that the concrete types must extend. For example, a type would provide an ability to interact with (now using dot-notation to acknowledge the existence of the bms baseclass) devices without utilizing any of the specialized “light” types. We would be aggressive about keeping the baseclass completely generic with some, possibly, containing no fields at all (i.e. since these would be considered abstract base classes). In such an eco-system it might even be a good idea to extend node.GetInfo to include a concrete device class type and base class type which we would assign (again, like USB 8-bit device classes and sub-classes). We could even go deeper down the USB rabbit-hole and add device protocol to allow versioning of the device classes (e.g. bms==0a, bms.light==01, protocol==01, meaning "this device is a lightweight bms supporting the first revision of the bms message set (yeah, that’s not exactly how USB protocols work but this is how I’d use it for UAVCAN)).