Topics

New Device Services & SDK Requirements document (v5)

espy
 

Attached please find the latest Device Services & SDK Requirements document (v5) for the California release of EdgeX Foundry.

Thanks for those of you that provided feedback on the previous version!

The following areas of the document have been clarified or updated:

* Query commands:
- mention that readings are triggered whenever a successful query command is processed
- clarify which Query GET handlers are required

* Data transformation - new section

* Actuation commands - clarified how command arguments are passed

* operatingState - clarified how device operatingStates are handled

* Security - new section

* Appendix A - Settings: minor cleanup

There still is some remaining work to flesh out the logging, scheduling, and metadata updates sections.

Please review and send my comments my way.

Regards,
/tony

Drasko DRASKOVIC
 

Hi Tony,
in your doc I can see that query commands sometime return strings:
{"AnalogValue_40":"183.92999267578125"}

This is simple, and of course make sense, just that ints, floats and
bools are all represented by strings and I guess that make messages
longer. It's not an issue now, but in the future, we might think about
constrained and battery-powered devices which send messages over
LPWAN, potentially aggregate several sensor readings and then send
them all at once (this is typical mode of operation).

IETF is trying to define semantics for sensor network JSON and CBOR
mesages through SenML standard:
https://tools.ietf.org/html/draft-ietf-core-senml-13

SenML is describing the type of the value, and can shorten the
aggregated messages. I think it is worth looking at.

Best regards,
Drasko DRASKOVIC
Mainflux Author and Technical Advisor

www.mainflux.com | Industrial IoT Cloud
-------------------------------------------------------------------
Engineering Division | Paris, France

LinkedIn: https://www.linkedin.com/in/draskodraskovic
Twitter: @draskodraskovic

On Tue, Mar 6, 2018 at 2:01 AM, espy <espy@...> wrote:
Attached please find the latest Device Services & SDK Requirements document
(v5) for the California release of EdgeX Foundry.

Thanks for those of you that provided feedback on the previous version!

The following areas of the document have been clarified or updated:

* Query commands:
- mention that readings are triggered whenever a successful query command
is processed
- clarify which Query GET handlers are required

* Data transformation - new section

* Actuation commands - clarified how command arguments are passed

* operatingState - clarified how device operatingStates are handled

* Security - new section

* Appendix A - Settings: minor cleanup

There still is some remaining work to flesh out the logging, scheduling, and
metadata updates sections.

Please review and send my comments my way.

Regards,
/tony

_______________________________________________
EdgeX-TSC-Security mailing list
EdgeX-TSC-Security@...
https://lists.edgexfoundry.org/mailman/listinfo/edgex-tsc-security

Steve Osselton
 

Hi Drasco,

Agree that this is the sort of representation that we should be looking at using.

Cheers Steve

On 6 March 2018 at 11:17, Drasko DRASKOVIC <drasko@...> wrote:
Hi Tony,
in your doc I can see that query commands sometime return strings:
{"AnalogValue_40":"183.92999267578125"}

This is simple, and of course make sense, just that ints, floats and
bools are all represented by strings and I guess that make messages
longer. It's not an issue now, but in the future, we might think about
constrained and battery-powered devices which send messages over
LPWAN, potentially aggregate several sensor readings and then send
them all at once (this is typical mode of operation).

IETF is trying to define semantics for sensor network JSON and CBOR
mesages through SenML standard:
https://tools.ietf.org/html/draft-ietf-core-senml-13

SenML is describing the type of the value, and can shorten the
aggregated messages. I think it is worth looking at.

Best regards,
Drasko DRASKOVIC
Mainflux Author and Technical Advisor

www.mainflux.com   |  Industrial IoT Cloud
-------------------------------------------------------------------
Engineering Division |   Paris, France

LinkedIn: https://www.linkedin.com/in/draskodraskovic
Twitter: @draskodraskovic

On Tue, Mar 6, 2018 at 2:01 AM, espy <espy@...> wrote:
> Attached please find the latest Device Services & SDK Requirements document
> (v5) for the California release of EdgeX Foundry.
>
> Thanks for those of you that provided feedback on the previous version!
>
> The following areas of the document have been clarified or updated:
>
>  * Query commands:
>    - mention that readings are triggered whenever a successful query command
> is processed
>    - clarify which Query GET handlers are required
>
>  * Data transformation - new section
>
>  * Actuation commands - clarified how command arguments are passed
>
>  * operatingState - clarified how device operatingStates are handled
>
>  * Security - new section
>
>  * Appendix A - Settings: minor cleanup
>
> There still is some remaining work to flesh out the logging, scheduling, and
> metadata updates sections.
>
> Please review and send my comments my way.
>
> Regards,
> /tony
>
> _______________________________________________
> EdgeX-TSC-Security mailing list
> EdgeX-TSC-Security@lists.edgexfoundry.org
> https://lists.edgexfoundry.org/mailman/listinfo/edgex-tsc-security
>

_______________________________________________
EdgeX-TSC-Security mailing list
EdgeX-TSC-Security@lists.edgexfoundry.org
https://lists.edgexfoundry.org/mailman/listinfo/edgex-tsc-security



--
Technical Director
IOTech Systems Ltd.

espy
 

On 03/06/2018 06:17 AM, Drasko DRASKOVIC wrote:
Hi Tony,
in your doc I can see that query commands sometime return strings:
{"AnalogValue_40":"183.92999267578125"}
Yes, that's correct.

This is simple, and of course make sense, just that ints, floats and
bools are all represented by strings and I guess that make messages
longer. It's not an issue now, but in the future, we might think about
constrained and battery-powered devices which send messages over
LPWAN, potentially aggregate several sensor readings and then send
them all at once (this is typical mode of operation).
IETF is trying to define semantics for sensor network JSON and CBOR
mesages through SenML standard:
https://tools.ietf.org/html/draft-ietf-core-senml-13
SenML is describing the type of the value, and can shorten the
aggregated messages. I think it is worth looking at.
Thanks for the suggestion! It looks like this is still a draft, so we should keep any eye on it as it progresses.

Some observations:

- the readings embed the device name, making it possible to combine readings from different devices in the same result array. EdgeX currently adds the device name to the event, which contains readings.

- the format allows custom attributes to be defined, which would allow us to add EdgeX specific attributes

- I don't think there's a big difference in size between our current messages and the JSON SenML format, in fact the latter messages might even be a bit larger than our current messages. That said, on constrained devices using CBOR would be an advantage.

Implementing this would require pretty invasive re-work across all of our services, so this is something we should put on our post-California architecture list.

Regards,
/tony



Best regards,
Drasko DRASKOVIC
Mainflux Author and Technical Advisor
www.mainflux.com | Industrial IoT Cloud
-------------------------------------------------------------------
Engineering Division | Paris, France
LinkedIn: https://www.linkedin.com/in/draskodraskovic
Twitter: @draskodraskovic
On Tue, Mar 6, 2018 at 2:01 AM, espy <espy@...> wrote:
Attached please find the latest Device Services & SDK Requirements document
(v5) for the California release of EdgeX Foundry.

Thanks for those of you that provided feedback on the previous version!

The following areas of the document have been clarified or updated:

* Query commands:
- mention that readings are triggered whenever a successful query command
is processed
- clarify which Query GET handlers are required

* Data transformation - new section

* Actuation commands - clarified how command arguments are passed

* operatingState - clarified how device operatingStates are handled

* Security - new section

* Appendix A - Settings: minor cleanup

There still is some remaining work to flesh out the logging, scheduling, and
metadata updates sections.

Please review and send my comments my way.

Regards,
/tony

_______________________________________________
EdgeX-TSC-Security mailing list
EdgeX-TSC-Security@...
https://lists.edgexfoundry.org/mailman/listinfo/edgex-tsc-security

Drasko DRASKOVIC
 

On Tue, Mar 6, 2018 at 7:19 PM, espy <espy@...> wrote:

Thanks for the suggestion! It looks like this is still a draft, so we
should keep any eye on it as it progresses.
Yes, it's still a draft, but it's 13th release - it has been crafted
over a number of years now and is pretty mature. When it comes to
standards, this is the probably the best I know (not ideal, but at
least it is IETF standard draft).


Some observations:

- the readings embed the device name, making it possible to combine
readings from different devices in the same result array. EdgeX currently
adds the device name to the event, which contains readings.

- the format allows custom attributes to be defined, which would allow us
to add EdgeX specific attributes
Sure, this is all good. My only remark is that it is EdgeX specific,
and I think it is good to align on some more generic standard, if
possible.


- I don't think there's a big difference in size between our current
messages and the JSON SenML format, in fact the latter messages might even
be a bit larger than our current messages. That said, on constrained
devices using CBOR would be an advantage.
I think that difference comes from aggregated sensor measurements.
I.e. one sensor that reads for example temperature every hour, but it
does not send the reading immediately, but rather keeps the readings
in internal flash, then sends all in one message once a day. SenML is
good at packing these kind of messages in the array of readings,
removing redundancy and making messages as small as possible. For
cellular IoT sensors it is very important, as bandwidth is expensive.
And for battery powered devices radio Tx/Rx is the biggest enemy of
battery budget.


Implementing this would require pretty invasive re-work across all of our
services, so this is something we should put on our post-California
architecture list.
I totally agree. I am not even sure that this is the best idea for
EdgeX, I was just pointing out SenML as a potentially good candidate
for standardized message semantics. We can do some research and
evaluation in later phases, post California MVP.

BR,
Drasko DRASKOVIC
Mainflux Author and Technical Advisor

www.mainflux.com | Industrial IoT Cloud
-------------------------------------------------------------------
Engineering Division | Paris, France

LinkedIn: https://www.linkedin.com/in/draskodraskovic
Twitter: @draskodraskovic

espy
 

On 03/06/2018 06:24 PM, Drasko DRASKOVIC wrote:
On Tue, Mar 6, 2018 at 7:19 PM, espy <espy@...> wrote:

Thanks for the suggestion! It looks like this is still a draft, so we
should keep any eye on it as it progresses.
Yes, it's still a draft, but it's 13th release - it has been crafted
over a number of years now and is pretty mature. When it comes to
standards, this is the probably the best I know (not ideal, but at
least it is IETF standard draft).


Some observations:

- the readings embed the device name, making it possible to combine
readings from different devices in the same result array. EdgeX currently
adds the device name to the event, which contains readings.

- the format allows custom attributes to be defined, which would allow us
to add EdgeX specific attributes
Sure, this is all good. My only remark is that it is EdgeX specific,
and I think it is good to align on some more generic standard, if
possible.
Sure, I was just pointing out that if needed, the standard supports extra fields, so if we need the extensibility, it's already builtin.

- I don't think there's a big difference in size between our current
messages and the JSON SenML format, in fact the latter messages might even
be a bit larger than our current messages. That said, on constrained
devices using CBOR would be an advantage.
I think that difference comes from aggregated sensor measurements.
I.e. one sensor that reads for example temperature every hour, but it
does not send the reading immediately, but rather keeps the readings
in internal flash, then sends all in one message once a day. SenML is
good at packing these kind of messages in the array of readings,
removing redundancy and making messages as small as possible. For
cellular IoT sensors it is very important, as bandwidth is expensive.
And for battery powered devices radio Tx/Rx is the biggest enemy of
battery budget.
All good points.

Implementing this would require pretty invasive re-work across all of our
services, so this is something we should put on our post-California
architecture list.
I totally agree. I am not even sure that this is the best idea for
EdgeX, I was just pointing out SenML as a potentially good candidate
for standardized message semantics. We can do some research and
evaluation in later phases, post California MVP.
+1

Thanks!
/tony