Interoperability

This working group is dedicated to editing the privacy section of the interoperability mark and as of June 16th on draft 0.1 reads as follows.

NB: The keywords “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”,  “MAY”, and “OPTIONAL” are used as described in RFC 2119.

Reference Model(non-normative, used for discussion)

Device, Gateway, Platform / Backend, Apps / 3rd party Services

[https://iot.eclipse.org/resources/white-papers/Eclipse IoT White Paper – The Three Software Stacks Required for IoT Architectures.pdf, licensed EPLv1.0]

“Allow others to talk to your cloud” (if there is a cloud)

IF you have cloud then you [MUST] comprehensively document its Application Programming Interface (API).

  1. Have an open platform API [MUST]
    1. with the same functional scope as provided to the native mobile app or web app.
    1. Cloud must be neutral and respond in the same way to a third party application as it does to the manufacturer’s application.
  1. Provide comprehensive platform API documentation [MUST]
    1. Endpoints (e.g. api.example.com)
    2. API (e.g. GET /things, e.g. described with Swagger)
    3. Protocol (e.g. HTTP, MQTT, …)
    4. Data format (e.g. JSON, XML; clearly defined data types)
    5. Data model / information model (e.g. service topics, how to measure temperature)

 

“Allow others to talk to your device”

IF you have a device then you [MUST] comprehensively document its “API”.

 

  • Have an open device “API” [MUST]
  • Provide comprehensive device “API” documentation [MUST]
    1. “API” (e.g. Bluetooth Profile)
    2. Protocol (e.g. CoAP, MQTT)
    3. Data format (e.g. binary encoding)
    4. Sensors / Actuators (what does it measure / control; inputs / outputs)

Authors on June 16th 2017 @ ZSL London Zoo @andysc, @borisadryan, @nullr0ute, @{?}, @tamberg

Advertisements