Details

    • Type: extRequest
    • Status: Closed
    • Priority: Major
    • Resolution: Done
    • Fix Version/s: 2021
    • Component/s: FIWARE-TECH-HELP
    • Labels:
      None

      Description

      Hi,

      I am investigating the role of independant processes in the IOT-'landscape'.

      On https://www.fiware.org/developers/ there is this picture with "Interfacing with the Internet of Things (IoT), Robots and third-party systems". Is there a standard on how (third-party) processes should expose (register/publish) themselves and how these processes can be found (by software, machine readable)?

      I hope you can point me to some usefull links.

      Kind regards,

      Inge La Rivière
      Researcher/Software Engineer
      Wageningen Environmental Research
      GAIA (Building 101) Droevendaalsesteeg 3, 6708 PB, Wageningen
      Tel. +31 317 487616.
      www.disclaimer-en.wur.nl<http://www.disclaimer-en.wur.nl/>

      __________________________________________________________________________________________

      You can get more information about our cookies and privacy policies on the following links:

      Fiware-tech-help mailing list
      Fiware-tech-help@lists.fiware.org

      To unsubscribe from Fiware-tech-help mailing list, go to the information page of the list at:
      https://lists.fiware.org/listinfo/fiware-tech-help

      [Created via e-mail received from: "La Riviere, Inge" <inge.lariviere@wur.nl>]

        Activity

        Hide
        jason.fox Jason Fox added a comment -

        Email sent.

        Certainly there are lots of standards on this, and I’ll try to supply some relevant information. However the actual method of getting information from a device to a context broker will

        vary depending upon the capabilities of the device.

        Let’s start with the standards:

        The NGSI v2 interface is defined here: https://fiware-ges.github.io/orion/api/v2/stable/ - This is the current basis of interoperability of all components of the FIWARE System

        NGSI-LD is an evolution of NGSI v2 for Linked Data is now an ETSI standard - it can be found here: https://www.etsi.org/deliver/etsi_gs/CIM/001_099/009/01.01.01_60/gs_CIM009v010101p.pdf

        The relevant Swagger definitions can be found:

        NGSI v2: https://fiware.github.io/specifications/OpenAPI/ngsiv2

        NGSI-LD: https://forge.etsi.org/swagger/ui/?url=https://forge.etsi.org/gitlab/NGSI-LD/NGSI-LD/raw/master/spec/updated/full_api.json

        Basically NGSI is a simple REST API with a JSON payload which defines three major operations:

        1) Basic CRUD operations align with the standard HTTP verbs as expected (Batch operations use POST as expected)

        2) Additional information can be retrieved from other sources using Registration operations

        3) Asynchronous events can be publish/subscribed using Subscription Operations

        The basic operations of a context broker are summarised in the first chapter of the tutorial information:

        https://fiware-tutorials.readthedocs.io/en/latest/getting-started/index.html

        So if I am a webservice wishing to register additional context I need to follow the standards of the registration endpoint

        And if I am a web service wanting to do anything with context data I need to be able to listen and interpret information received by the subscription endpoint.

        This is how all of the other elements in the FIWARE Catalogue interact with the context broker:

        https://github.com/FIWARE/catalogue

        Moving on to IoT devices you have three options:

        1) For a high power device it could use the NGSI interfaces directly

        2) For a low power device there would be another Edge component such as an IoT Agent

        3) It is possible to use a third party IoT Platform (e.g. Watson) which then connects to a component which eventually talks NGSI.

        Option 2) is the usually method of communication with IoT devices - there needs to be some communication layer (IoT protocol => NGSI and back again)

        There is an existing library which offers an administration interface and can be mapped to a wide variety of Protocols and payloads:

        https://github.com/FIWARE/specifications/tree/master/OpenAPI/iot.IoTagent-node-lib

        An example of how it works can be seen here: https://www.youtube.com/watch?v=my6Kgiqx-OM&list=PLR9elAI9JscTyBVUq0P48OMVkrbdPitB7

        An example of Option 3) would be the FIWARE contribution to Node RED

        https://github.com/FIWARE/node-red-contrib-FIWARE_official

        Of course robotic devices have their own protocols - FIWARE is linked to Fast-RTPS which is part of the ROS2 standard. There is also a connector

        for the old ROS1 standard - more information can be found under here:

        https://github.com/FIWARE/catalogue/tree/master/robotics

        Specifically regarding agriculture, there is an ongoing initiative to promote a series of standard data models so that what you call a humidity reading

        Is the same as what I call a humidity reading for example - the data models can be found here:

        https://github.com/FIWARE/data-models/tree/master/specs/AgriFood

        The NGSI standard is very open and flexible in that you only need a type and an id - all other attributes are self describing and optional. Linked Data

        (NGSI-LD) uses the mechanisms defined in the JSON-LD 1.0 standard (http://JSON-ld.org) to ensure that data can be locked down to be

        consistent (using a schema) and interoperable (using JSON-LD)

        A full definition of a data model, including a JSON-LD @context and @graph along with a JSON schema will ensure that machines can read

        and interpret separate context data sources.

        I hope this short introduction will be useful, further technical learning materials can be found on the FIWARE Academy:

        https://fiware-academy.readthedocs.io/

        Show
        jason.fox Jason Fox added a comment - Email sent. Certainly there are lots of standards on this, and I’ll try to supply some relevant information. However the actual method of getting information from a device to a context broker will vary depending upon the capabilities of the device. Let’s start with the standards: The NGSI v2 interface is defined here: https://fiware-ges.github.io/orion/api/v2/stable/ - This is the current basis of interoperability of all components of the FIWARE System NGSI-LD is an evolution of NGSI v2 for Linked Data is now an ETSI standard - it can be found here: https://www.etsi.org/deliver/etsi_gs/CIM/001_099/009/01.01.01_60/gs_CIM009v010101p.pdf The relevant Swagger definitions can be found: NGSI v2: https://fiware.github.io/specifications/OpenAPI/ngsiv2 NGSI-LD: https://forge.etsi.org/swagger/ui/?url=https://forge.etsi.org/gitlab/NGSI-LD/NGSI-LD/raw/master/spec/updated/full_api.json Basically NGSI is a simple REST API with a JSON payload which defines three major operations: 1) Basic CRUD operations align with the standard HTTP verbs as expected (Batch operations use POST as expected) 2) Additional information can be retrieved from other sources using Registration operations 3) Asynchronous events can be publish/subscribed using Subscription Operations The basic operations of a context broker are summarised in the first chapter of the tutorial information: https://fiware-tutorials.readthedocs.io/en/latest/getting-started/index.html So if I am a webservice wishing to register additional context I need to follow the standards of the registration endpoint And if I am a web service wanting to do anything with context data I need to be able to listen and interpret information received by the subscription endpoint. This is how all of the other elements in the FIWARE Catalogue interact with the context broker: https://github.com/FIWARE/catalogue Moving on to IoT devices you have three options: 1) For a high power device it could use the NGSI interfaces directly 2) For a low power device there would be another Edge component such as an IoT Agent 3) It is possible to use a third party IoT Platform (e.g. Watson) which then connects to a component which eventually talks NGSI. Option 2) is the usually method of communication with IoT devices - there needs to be some communication layer (IoT protocol => NGSI and back again) There is an existing library which offers an administration interface and can be mapped to a wide variety of Protocols and payloads: https://github.com/FIWARE/specifications/tree/master/OpenAPI/iot.IoTagent-node-lib An example of how it works can be seen here: https://www.youtube.com/watch?v=my6Kgiqx-OM&list=PLR9elAI9JscTyBVUq0P48OMVkrbdPitB7 An example of Option 3) would be the FIWARE contribution to Node RED https://github.com/FIWARE/node-red-contrib-FIWARE_official Of course robotic devices have their own protocols - FIWARE is linked to Fast-RTPS which is part of the ROS2 standard. There is also a connector for the old ROS1 standard - more information can be found under here: https://github.com/FIWARE/catalogue/tree/master/robotics Specifically regarding agriculture, there is an ongoing initiative to promote a series of standard data models so that what you call a humidity reading Is the same as what I call a humidity reading for example - the data models can be found here: https://github.com/FIWARE/data-models/tree/master/specs/AgriFood The NGSI standard is very open and flexible in that you only need a type and an id - all other attributes are self describing and optional. Linked Data (NGSI-LD) uses the mechanisms defined in the JSON-LD 1.0 standard ( http://JSON-ld.org ) to ensure that data can be locked down to be consistent (using a schema) and interoperable (using JSON-LD) A full definition of a data model, including a JSON-LD @context and @graph along with a JSON schema will ensure that machines can read and interpret separate context data sources. I hope this short introduction will be useful, further technical learning materials can be found on the FIWARE Academy: https://fiware-academy.readthedocs.io/

          People

          • Assignee:
            jason.fox Jason Fox
            Reporter:
            fw.ext.user FW External User
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: