Data Types Should Include Optional Limits

[shaggygi]

Data types should have a way to represent limits like minimum and maximum.

Example:

{
            "@id": "http://MyDevice.com/MySensor/1.0.0",
            "@type": "Interface",
            "displayName": "My Sensor",
            "contents": {
                "@id": "http://MyDevice.com/MySensor/1/input",
                "@type": "Telemetry",
                "description": "Voltage",
                "displayName": "Input Monitor",
                "name": "input",
                "displayUnit": "volts",
                "schema": "double",
                "minimum": "0",
                "maximum": "5.0",
            }
        },

[briancr-ms]

Thanks for your feedback on limits for capabilities in an interface. One idea that we've discussed is that there may be multiple ranges or limits as an interface is developed. For example, a manufacturer may want to specify a manufacturer range--the temperature sensor can physically measure -1000 to +1000 degrees. However, a connected product builder may want to specify an operating range--the same temperature sensor, in the product, should be limited to -100 to +100.

One approach we've thought about is to use "semantic types" (additional @type specifications) that would allow those various ranges to be specified separately, but also combined together, if desired.

We're interested in your feedback on this idea.

An example, using your interface definition from above, could work like this.

{
    "@id": "http://MyDevice.com/MySensor/1.0.0",
    "@type": "Interface",
    "contents": {
        "@type": [ "Telemetry", "ManufacturerRange", "OperationalRange" ],
        "name": "input",
        "schema": "double",
        "ManufacturerRange/min": -1000,
        "ManufacturerRange/max": 1000,
        "OperationalRange/min": -100,
        "OperationalRange/max": 100
    }
}

What feedback do you have on an approach like this?

[askpatrickw]

In your example, I believe you're describing a capability and an operational threshold.

I'm curious how a plug-n-play device that could be used in many use cases and thus have many operational thresholds would be managed?

Would you see the solution developer defining a custom DTDL for each scenario? Would they override the defaults of the device?

[phelter]

Looks like this issue is fairly stagnant.

Prior to DTDL, i've used the jsonSchema validation for identifying thresholds and limits on particular elements as well as checking the schema produced by the iot-device is valid; however, this means duplicating the schema format of Azure IoT for request/response values, and not having the code auto-generated. The jsonSchema was then used as an input (read and parsed) for verification/validation testing of the IoT device updating the Device Twins when the values presented are within the limits, and No UPDATE (error value) when the values presented are outside the limits of the jsonSchema defined device twin.

Since you are providing a schema-like language for Device Twins specifically - it would be advantageous to have the iot-device code generated detect range min/max for integers/numbers, as well as maxLength for strings as well as other limitations to decide whether the schema message is valid before acting upon it inside the iot-device embedded code. If it is part of the generated code, then you validate the generated code always creates the checks appropriately and then don't need the verification/validation of the resulting code.

Based on the definition of DTDL, I believe these should be wherever schema is used and be part of being inside an Interface. And yes a custom DTDL for each scenario - or possibly support a means to use extends to limit the values of an interface.