Homepage GitHub

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 uavcan.org 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 uavcan.org 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