device categories - initial draft

[mlagally]

---

Preview | Diff

[mlagally]

Arch call on 25.2.
Node terminology discussion:

• constrained node
• sensor node
• directly associated with a sensor or actuator

small, mid size, large category, roles can overlap
constrained

BACnet controller - S7, couple of MB?

Let's align with building on top of IETF's class definitions RFC-7228:
n= 50 kb class defined by IETF
Class-n+1 = 64KB - 128KB
Class n+2 = 128KB - 512KB
Class n+3 = 512KB -

[mlagally]

Classes 0 and 1 are identical to IETF's definition.

Other device examples:
https://customer.honeywell.com/resources/techlit/TechLitDocuments/31-00000s/31-00100.pdf
CPUEach controller uses a 32 bit ATMEL ARM 7 microprocessor.Memory CapacityFlash Memory: 512 kilobytes. The controller is able to retain Flash memory settings for up to ten (10) years.RAM: 128 kilobytes

https://www.w3schools.com/bootstrap/bootstrap_grid_small.asp there is some definition for device classification based on the screen size (but I personally think we should rather use more neutral term like "class")

[sebastiankb]

small does not imply resource constrained. Constrained or resource constrained embedded devices (like field devices) is more common.

[sebastiankb]

node only is unspecific. resource constrained node

typically 64-128 KB of RAM

I'm not sure about such a range. I would simple say typically KB of RAM

[sebastiankb]

I'm not 100% sure why such a generic section have to be introduced in the core profile. It should be more provided in the architecture document. On the other hand, WoT claims to be a kind of hardware and platform independence. Thats the reason why WoT is so interesting! So I'm not sure if we need such text at all.

If this is the reason for the motivation to limit the TD size, then we must first discuss the concrete scenarios as already mentioned here.

[benfrancis]

@mlagally What are you hoping to achieve by defining these classes of device? It all seems arbitrary to me and of little practical use. Hardware is always evolving and the software/firmware running on a device in addition to any software that might be used for processing Thing Descriptions will vary greatly.

It may be useful to provide a separate profile for constrained devices which uses a different protocol and serialisation format and imposes additional constraints, but given the number of variables in terms of resource needs, is it not better to leave it up to developers which profile is best suited to their particular use case?

[mlagally]

@benfrancis
In recent architecture calls we had quite some conversation cycles because of using terms like ESP, Raspberry, Gateway, Node MCU, ...
In a W3C spec we cannot make reference to products and rather want to talk about capabilities of devices.
This classification helps to ask questions like: Can a TD consumer be implemented in a Class-X devices, and if yes, what kind of constraints does that imply.
One possible outcome of the discussion is to exclude some classes from the consumer role.

[benfrancis]

This classification helps to ask questions like: Can a TD consumer be implemented in a Class-X devices, and if yes, what kind of constraints does that imply.

I just don't think it's possible to generalise answers to these types of questions. An HTTP+JSON profile could be used by a $5 microcontroller while a $5m satellite with a state of the art multi-core processor may want to use a CoAP+CBOR profile due to low network speeds/high latency. It really depends on the individual use case.

One possible outcome of the discussion is to exclude some classes from the consumer role.

I'm surprised that you use the consumer in this example, as I would have though that it's the producer which is more likely to be a constrained device, which just further demonstrates how difficult it is to provide general answers to such questions.

I would instead propose that it is enough to assume that many WoT devices (and gateways, and clients) could support an HTTP+JSON profile with a large amount of human readable metadata, but some WoT devices (and clients) may be better suited to a CoAP+CBOR profile with more condensed metadata. It would then be up to developers to choose which profile is the best fit for their implementation.

[mlagally]

@benfrancis
The initial question that triggered the discussion was: What contraints do we have to consider if we implement a consumer on a resource constrained device. A deployment scenario is a connected set/network of sensors in a mesh.
There may be a gateway, but it could be only offering proxy functionality to the outside world, no directory, just P2P discovery - you could think of a UPnP like discovery / usage scenario.

This is a P2P deployment where a Class-2-3 device consumes the TD of another Class 2-3 device to receive telemtry data or control the device.

One comment about your remark:
"It would then be up to developers to choose which profile is the best fit for their implementation."

The profile work targets business customers, who select off-the-shelf devices that fit with their needs, i.e. they guarantee to work in their environment for their intended use cases. This is the core point of the profile: Have devices that have a guaranteed deterministic behavior within assured operation ranges. It is a bit like the MIL standard for chips that guarantees that compliant devices operate within specified temperature bounds.
In our case these limits are size and complexity.

The development model is that individual devices are built by different companies who do not know each other, i.e. use only the TD for communicating about their capabilities.
The end user is NOT a developer who knows the difference between CBOR and JSON but just inspects the label on the device carton to find out if the device works for him.

[benfrancis]

@mlagally wrote:

What contraints do we have to consider if we implement a consumer on a resource constrained device.

OK, thank you for explaining where the requirement comes from. I guess I just haven't come across a use case where the consumer has more constrained hardware than the producer, at least not to the extent that the size of a Thing Description would be the limiting factor. The firmware/software stack needed to fetch and parse any TD and send and receive data from the device it describes seems likely to use an order of magnitude more resources than the metadata describing the device's capabilities (its TD).

A deployment scenario is a connected set/network of sensors in a mesh.

Is this an actual scenario that has come up in PlugFests, or just a theoretical one? The Web of Things seems ill suited to implementing a mesh network of constrained devices (there are much better protocols available for that like Zigbee/Z-Wave/Bluetooth/Thread), but it can act as a web-based abstraction layer above the mesh networking layer using a client-server model.

I'm not assuming that a gateway is always involved, but I do think that in practice it's likely that most WoT consumers are either a gateway, cloud service or a desktop/mobile application.

Even if we assume that TDs will be used for device to device interactions on constrained devices, I don't see that setting arbitrary limits on the size of a TD really helps much since the size of the TD is only one small factor in the resources needed to communicate with a device.

I understand the problem you're trying to solve, but I really don't believe that the size of Thing Descriptions is what's preventing interoperability. In my opinion we should focus less on adding arbitrary constraints to an abstract data model and more on defining a finite set of protocols and serialisation formats conformant devices must support and how they are used.

[mlagally]

Resolution in vF2F on June 23: Retarget to arch specification

[mlagally]

This section was retargeted to the architecture spec, this MR can be closed.