# Data type regulation policy and membership fees **URL:** \ **Category:** Development & Maintenance\ **Created:** [December 8, 2019, 6:55am UTC](https://forum.opencyphal.org/t/data-type-regulation-policy-and-membership-fees/707 "2019-12-08T06:55:57Z")\ **Posts on this page:** 20\ **Page:** 1
**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:** [December 8, 2019, 6:55am UTC](https://forum.opencyphal.org/t/data-type-regulation-policy-and-membership-fees/707/1 "2019-12-08T06:55:57Z")
@lorenz.meier predicts that the current set of [regulated data type](https://github.com/UAVCAN/public_regulated_data_types/pull/73) 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](https://www.usb.org/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 ---
**Author:** ![scottdixon](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/scottdixon/32/39_2.png) [@scottdixon](https://forum.opencyphal.org/u/scottdixon)\ **Post date:** [December 13, 2019, 7:08pm UTC](https://forum.opencyphal.org/t/data-type-regulation-policy-and-membership-fees/707/2 "2019-12-13T19:08:42Z")
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](https://www.bluetooth.com/develop-with-bluetooth/qualification-listing/)) 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](http://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](http://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. ---
**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:** [December 13, 2019, 8:42pm UTC](https://forum.opencyphal.org/t/data-type-regulation-policy-and-membership-fees/707/3 "2019-12-13T20:42:49Z")
> [@scottdixon](#): > > 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. 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](https://forum.opencyphal.org/t/on-standards-and-regulation/260)_. 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. > [@scottdixon](#): > > 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 agree. ---
**Author:** ![ka\_ru](https://forum.opencyphal.org/letter_avatar_proxy/v4/letter/k/94ad74/32.png) [@ka\_ru](https://forum.opencyphal.org/u/ka_ru)\ **Post date:** [December 25, 2019, 7:17am UTC](https://forum.opencyphal.org/t/data-type-regulation-policy-and-membership-fees/707/4 "2019-12-25T07:17:34Z")
> [@Uavcan and raspberry pi](https://forum.opencyphal.org/t/uavcan-and-raspberry-pi/592/13): > > As explained in [Data type regulation policy and membership fees](https://forum.opencyphal.org/t/data-type-regulation-policy-and-membership-fees/707), the idea is to enable vendors to collaborate on abstract, reusable interfaces in a well-regulated fashion. In the longer term, we will use regulated vendor namespaces (such as regulated.zubax) as a base to define standard vendor-agnostic profiles. Keeping such generic namespaces in one repository is necessary to reduce the risk of fragmentation and to simplify their maintenance. I don’t think the name of a namespace could prevent … “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? ☹ Never. ---
**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:** [December 26, 2019, 10:19pm UTC](https://forum.opencyphal.org/t/data-type-regulation-policy-and-membership-fees/707/5 "2019-12-26T22:19:12Z")
> [@ka\_ru](#): > > Do you think that a company producing controllers will use data types of another company? ☹ Never. Could you please elaborate why do you believe that this might be an obstacle? ---
**Author:** ![ka\_ru](https://forum.opencyphal.org/letter_avatar_proxy/v4/letter/k/94ad74/32.png) [@ka\_ru](https://forum.opencyphal.org/u/ka_ru)\ **Post date:** [December 26, 2019, 11:07pm UTC](https://forum.opencyphal.org/t/data-type-regulation-policy-and-membership-fees/707/6 "2019-12-26T23:07:03Z")
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? 🙂 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. ---
**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:** [December 27, 2019, 12:37pm UTC](https://forum.opencyphal.org/t/data-type-regulation-policy-and-membership-fees/707/7 "2019-12-27T12:37:51Z")
Thank you for the elaboration. We have addressed the legal aspects by distributing all public regulated data types under the [MIT license](https://tldrlegal.com/license/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? ---
**Author:** ![ka\_ru](https://forum.opencyphal.org/letter_avatar_proxy/v4/letter/k/94ad74/32.png) [@ka\_ru](https://forum.opencyphal.org/u/ka_ru)\ **Post date:** [December 28, 2019, 7:42am UTC](https://forum.opencyphal.org/t/data-type-regulation-policy-and-membership-fees/707/8 "2019-12-28T07:42:14Z")
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\>? ---
**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:** [December 29, 2019, 5:34pm UTC](https://forum.opencyphal.org/t/data-type-regulation-policy-and-membership-fees/707/9 "2019-12-29T17:34:43Z")
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](https://en.wikipedia.org/wiki/List_of_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. ---
**Author:** ![ka\_ru](https://forum.opencyphal.org/letter_avatar_proxy/v4/letter/k/94ad74/32.png) [@ka\_ru](https://forum.opencyphal.org/u/ka_ru)\ **Post date:** [December 30, 2019, 3:20am UTC](https://forum.opencyphal.org/t/data-type-regulation-policy-and-membership-fees/707/10 "2019-12-30T03:20:00Z")
My? 🙂 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. ---
**Author:** ![ka\_ru](https://forum.opencyphal.org/letter_avatar_proxy/v4/letter/k/94ad74/32.png) [@ka\_ru](https://forum.opencyphal.org/u/ka_ru)\ **Post date:** [December 31, 2019, 11:14am UTC](https://forum.opencyphal.org/t/data-type-regulation-policy-and-membership-fees/707/11 "2019-12-31T11:14:06Z")
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? 🙂 ---
**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:** [January 9, 2020, 1:20pm UTC](https://forum.opencyphal.org/t/data-type-regulation-policy-and-membership-fees/707/12 "2020-01-09T13:20:28Z")
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. > [@ka\_ru](#): > > There is a metric system SI. What to do with England and America? SI is an _international_ system, so no special cases are needed. ---
**Author:** ![lucas](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/lucas/32/164_2.png) [@lucas](https://forum.opencyphal.org/u/lucas)\ **Post date:** [January 29, 2020, 11:12am UTC](https://forum.opencyphal.org/t/data-type-regulation-policy-and-membership-fees/707/13 "2020-01-29T11:12:44Z")
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). ---
**Author:** ![noxuz](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/noxuz/32/397_2.png) [@noxuz](https://forum.opencyphal.org/u/noxuz)\ **Post date:** [January 30, 2020, 10:30pm UTC](https://forum.opencyphal.org/t/data-type-regulation-policy-and-membership-fees/707/14 "2020-01-30T22:30:03Z")
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. ---
**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:** [January 31, 2020, 5:57pm UTC](https://forum.opencyphal.org/t/data-type-regulation-policy-and-membership-fees/707/15 "2020-01-31T17:57:09Z")
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: > > > New stuff: > > \- Minor refactoring of unstable data types in \`uavcan.time\` to fac…ilitate their reuse in future application-specific namespaces. No semantic changes. > \- Added new SI types for force, torque, and frequency. Torque and frequency are used in the new namespace, force is added for completeness. > \- Added an application-specific namespace \`robotics\` (read below) intended for software-defined vehicular systems at large. The new namespace contains data types for the following applications so far: > - ESC, primarily intended for multirotors and other types of electric aircraft. > - Smart battery (BMS). > \- Updated the documentation in the README. > > This pull request should resolve the recurring argument about the removal of application-specific data types from the standard set in UAVCAN v1. A few months ago, it prompted Scott to write a \[FAQ entry\](https://forum.uavcan.org/t/uavcan-v1-faq-s/479?u=pavel.kirienko) specifically about standard data types; also, our \[presentation\](https://forum.uavcan.org/t/uavcan-a-highly-dependable-publish-subscribe-protocol-for-real-time-intravehicular-networking/557) at the PX4 dev summit addressed the problem with the help of the following infographic: > > !\[typecat\](https://user-images.githubusercontent.com/3298404/67565714-c0665900-f72e-11e9-8260-1576a3d6b8bf.jpg) > > Originally, the intent was to arrange regulated application-specific data types (such as BMS messages) in several categories, named \*profiles\*, and dedicate a separate namespace to each profile: > > !\[profiles\](https://user-images.githubusercontent.com/3298404/67566574-cfe6a180-f730-11e9-9b9a-8cc90dfabd84.png) > > Upon a closer assessment, I concluded that a \*strict\* separation may be undesirable because the protocol encourages similar approaches to common problems that may be encountered in different application domains. If the original plan was followed, it would likely lead to a noticeable overlap between the functionalities offered by different profiles. > > In this PR, I am proposing a modified approach that is closer to the model of a generic robotics framework, where all profile-agnostic functionality is extracted into a generic namespace under a sufficiently generic name. I found \`robotics\` to suit the purpose, but new suggestions are welcome. This change does not preclude the addition of profile namespaces later, shall the need arise. > > You will notice that the definitions lack fixed port-identifiers. This is by design: excessive reliance on those was one of the major problems in v0. The related issues are briefly explained in the \[recap of the Stockholm Summit\](https://forum.uavcan.org/t/stockholm-summit-recap/170). For the few (very few) types where a fixed port-ID will be found to be desirable one can always be added later, since it does not affect backward compatibility. > > Right now, the main objective is to establish the general architecture. Once it is accepted, I am planning to extend the namespace with new commonly needed types such as GNSS positioning messages and related generic geometric types. > > I invite the following people to look at the definitions and the namespace design to ensure their adequacy: > > \- Approach and architecture: @thirtytwobits @kjetilkjeka @antoinealb @eshamaev > \- ESC group messages: @dimracer > \- BMS messages: @dimracer @AlexKlimaj @igalloway > \- FYI: @mrpollo ---
**Author:** ![lucas](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/lucas/32/164_2.png) [@lucas](https://forum.opencyphal.org/u/lucas)\ **Post date:** [February 5, 2020, 2:11pm UTC](https://forum.opencyphal.org/t/data-type-regulation-policy-and-membership-fees/707/16 "2020-02-05T14:11:54Z")
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. ---
**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:** [February 5, 2020, 2:59pm UTC](https://forum.opencyphal.org/t/data-type-regulation-policy-and-membership-fees/707/17 "2020-02-05T14:59:00Z")
Sure. What you are describing has been available in v1.0 since day one. You can find the details in the Specification: > **[UAVCAN\_Specification\_v1.0-beta.pdf](https://uavcan.org/specification/UAVCAN_Specification_v1.0-beta.pdf)** > > 712.40 KB ---
**Author:** ![lucas](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/lucas/32/164_2.png) [@lucas](https://forum.opencyphal.org/u/lucas)\ **Post date:** [February 26, 2020, 12:16pm UTC](https://forum.opencyphal.org/t/data-type-regulation-policy-and-membership-fees/707/18 "2020-02-26T12:16:36Z")
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… ---
**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:** [April 16, 2020, 9:29pm UTC](https://forum.opencyphal.org/t/data-type-regulation-policy-and-membership-fees/707/19 "2020-04-16T21:29:37Z")
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](https://forum.opencyphal.org/t/uavcan-a-highly-dependable-publish-subscribe-protocol-for-real-time-intravehicular-networking/557): ![image](https://forum.opencyphal.org/uploads/default/original/1X/df5c00c8448e11136068c9fddfa77ea34e6dcc56.png) 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](https://github.com/UAVCAN/public_regulated_data_types/pull/73#issuecomment-546442302). 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](https://github.com/UAVCAN/specification/issues/3). 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 **`regulated.sensor.bms.BatteryPackStatus.1.0`** (currently, it’s under `regulated.zubax.sensor.bms.BatteryPackStatus.1.0`). [This is unlikely to work because we lack the required expertise](https://github.com/UAVCAN/public_regulated_data_types/pull/73#issuecomment-546442302). ---
**Author:** ![scottdixon](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/scottdixon/32/39_2.png) [@scottdixon](https://forum.opencyphal.org/u/scottdixon)\ **Post date:** [April 25, 2020, 5:58pm UTC](https://forum.opencyphal.org/t/data-type-regulation-policy-and-membership-fees/707/20 "2020-04-25T17:58:19Z")
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 **regulated.generic.bms** type would provide an ability to interact with **regulated.class.bms.light** (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)). [Next page](https://forum.opencyphal.org/t/data-type-regulation-policy-and-membership-fees/707.md?page=2)