[Fiware-iot] Feedback Thing Management Architecture

[Martin Bauer]

Hi Ricardo, all,

Some comments from my side on the discussion so far (I extracted them from Ricardo's e-mail that is attached below).


-          Actuation
Well, it is not so easy, as the general assumptions that seem to have been made for the Thing Management Architecture may not hold for actuation. There should be "Actuation IoT Resources" and based on a given Thing ID and what should be actuated, a suitable IoT resource should be found and then it should be possible to contact this resource. Neither the interface for finding he IoT resource, nor the type of interaction that allows contacting the resource is currently foreseen in the TID proposal.
 Yes it was simply left out, this topic would need an extra discussion and analysis, I think it is not the main priority at this time, but is important to include now all the points we have to take into account, OK.
The point was not that actuation should directly be part of the picture - it can indeed be discussed later. It is just that, from my point of view, the requirements on the "Discovery and Resolution of Things GE" that come from actuation are not fulfilled by the proposed architecture, i.e., T5.2 would not be fulfilling the requirements of T5.3 in this case (regarding functionality that in principle should be provided by T5.2).


-          IoT Reference Architecture
We at NEC have started to look into the Thing Management Architecture proposal made by Telefonica. Up to now we had assumed (also from the high-level architecture document) that the architecture would be closer to IoT-A/SENSEI.

I'm not sure why you assume that, for me is only a global reference architecture for the IoT world, this world would include IoT-A and Sensei as well, why not.

The goal of IoT-A is to develop a reference architecture for the IoT that exposes a number of design choices with different options. Your "reference architecture" already makes these choices, so from an IoT-A perspective, it is rather a derived architecture of a concrete instance. It may be possible to argue that your instance architecture can somehow be mapped to the IoT-A reference architecture (I still see some problems, but maybe we should check that). However, it is incompatible in important points with the SENSEI instance architecture (see the e-mail I sent yesterday regarding this topic).  Btw. the SENSEI architecture was significantly shaped to be the way it is by TID colleagues.


-          OMA NGSI-9
As you say, some of these operations are not supported in OMA NGSI-9 so we will have to define an API which would also be exported by the "Things/Resources Configuration Management" component.   So, my point of view is that those extensions would fit in the OMA-NGSI extension, indeed we can provide later those extension to OMA suggesting their inclusion in the standard.
Anyway a question to analyze is whether we should go for extending NGSI-9 and fast-track results of such extension to OMA.

The idea of the OMA NGSI interfaces is to define external enabler interfaces, which do NOT define architecture of the enablers themselves. Therefore, anything that is specific to the internal architecture of the enabler has no place in the OMA NGSI interfaces. An NGSI context enabler may or may not use IoT Services/resources as its basis, so such a concept has no place in OMA-NGSI.


-          Interaction with Resources
We currently do not see how Thing-based actuation can be supported in this approach as this required a resolution to IoT resources and then a direct interaction with these resources. (We also see use cases where queries should be directly forwarded to Iot Resources.)
 Every Thing are described based on values that properties linked to Things take over time (resources' capabilities), so you wouldn't need necessarily direct interaction with its associated resources .
We argue that certain (application) requirements cannot be supported without a (mediated) interaction between applications an resources, i.e., it is not sufficient to have data from resources, but you need to be able to interact with resources (mediated through the IoT system).


-          Workflows/Processes
Finally, the business processes/workflows planned in T5.4 require the Thing-based look-up/discovery of IoT Resources, which should then be directly
integrated into the process execution.
OK, right, and do you see in those slides any constraint for that? Discovery processes can be based also on Things with this model of architecture.

Well, the idea would be that you include IoT Resouces/Services as part of your workflow and you would need to find these based on a specification of Things. So you would need to retrieve associations specifying things and what you are interested (e.g. the attribute you want to retrieve or change) and get back the identifier of the IoT Service/Resource to then directly interact with that and integrate it into your workflow/process. - I do not see this currently supported as there is a complete decoupling.

Best regards,

Martin

------------------------------------------
Dr. Martin Bauer
Senior Researcher
NEC Europe Ltd.
NEC Laboratories Europe
Software & Services Research Division
Kurfürsten-Anlage 36
D-69115 Heidelberg
Tel: +49/ (0)6221/4342-168
Fax: +49/ (0)6221/4342-155
E-Mail: Martin.Bauer at neclab.eu<mailto:Martin.Bauer at neclab.eu>
http://www.nw.neclab.eu<http://www.nw.neclab.eu/>

*************************************************************
NEC Europe Limited
Registered Office: NEC House, 1 Victoria Road, London W3 6BL
Registered in England 2832014

From: Ricardo de las Heras [mailto:rheras at tid.es]
Sent: Freitag, 13. Januar 2012 12:38
To: Bisztray, Denes (NSN - HU/Budapest); Martin Bauer; fiware-iot at lists.fi-ware.eu
Cc: JUAN JOSE HIERRO SUREDA; Ricardo de las Heras
Subject: Re: [Fiware-iot] Feedback Thing Management Architecture

Hi Martin, Tobias, Denes, @ll,

first thank you for you feedback,
now I answer to all of you in-line, joining all your comments in this mail:

Bisztray, Denes (NSN - HU/Budapest) wrote:
Hi all,

Other questions emerge from Ricardo's slide:


-          The slide description says that the Configuration Repository contains "What are the relationships between IoT resources and Things and between Things themselves". However, the Inference Engine contains Association Rules. What are the difference between these two?
            Yes, Conf.Repository contains explicit relations (ex: these 2 sensors within the room A), however the Inference engine contains the Rules for generating new associations not explicitly defined yet, as for example 'if this sensor S1 is in room A, and room and is on the 1st floor, the inference defines a new association between S1 and the 1st floor, based on rules.


-          There is an incoming arrow to the Inference engine that enables rule editing. The Inference Engine reads and writes the configuration repository. What else does it do? No other connections? What is it exactly for?
            I think the previous example answer your question, those rules define the condition for create new associations, either static o dynamic.


-          Although previously I mentioned that there is an Event Store in Data Handling, it is still curious who accesses it?
            I'm not going to define concepts out of the scope of T5.2, but from my point of view applications are subscribed to events through a set of rules, it would be managed by Data Handling.


-          Why is the Portal component within IoT? Is it part of the backend?
           The block named portal supplies a front-end in order to manage the associations rules, things-resources config. management, etc., we need in some way to provide this interface to the user administrator.


-          Only resources or gateways can register themselves from the southbound ETSI M2M interface? Can we have virtual things that may be calculated from actual devices? How do they fit into this architecture?
            At this time I don't know what other type of elements could use the southbound interface as well for registering themselves.
            Virtual things maybe can be managed using a CEP for example, defining the way you combine two real sensors for creating a new one named 'virtual'.


-          Why are the list of resources in the configuration management. I assumed they are already stored within the Services and Resources interaction GE. Is this a duplicate? Does the architecture of that GE change?
            Please don't imagine strange ideas, this component manages the catalog of Things, Resources and their associations (including properties, capabilities, etc) as it is explained in the text window associated to the 2nd slide. In the T5.2 high level architecture are called Things manager and Resource Directory.


-          The actuation part is definitely missing from the sketch. It is important to cater for that need. Either the Configuration Management or the Inference Engien should contain some kind of execution component that resolves the tasking requests toward devices or gateways.

        You are right, the data flows should consider that specific commands could be send to actuators, having in some way an engine defining the set of rules to fulfill in order to trigger a command to an actuator. But it could be managed in many ways. It is out of the scope of T5.2 and should be discussed within T5.3 I think.

This is a first batch of questions. I hope they do make sense.
 Best,
Dénes

From: ext Martin Bauer [mailto:Martin.Bauer at neclab.eu]
Sent: Wednesday, January 11, 2012 1:58 PM
To: Bisztray, Denes (NSN - HU/Budapest); fiware-iot at lists.fi-ware.eu<mailto:fiware-iot at lists.fi-ware.eu>
Cc: ext Ricardo de las Heras
Subject: RE: [Fiware-iot] Feedback Thing Management Architecture
 Hi Denes, all,

 -          Thing-level actuation is not present on the slides, but they seem to be simply left out. I think we can iterate on including it.
Well, it is not so easy, as the general assumptions that seem to have been made for the Thing Management Architecture
may not hold for actuation. There should be "Actuation IoT Resources" and based on a given Thing ID and what should be actuated,
a suitable IoT resource should be found and then it should be possible to contact this resource. Neither the interface for finding
the IoT resource, nor the type of interaction that allows contacting the resource is currently foreseen in the TID proposal.

Yes it was simply left out, this topic would need an extra discussion and analysis, I think it is not the main priority at this time, but is important to include now all the points we have to take into account, OK.

Best regards,

Martin


From: Bisztray, Denes (NSN - HU/Budapest) [mailto:denes.bisztray at nsn.com]
Sent: Mittwoch, 11. Januar 2012 13:52
To: fiware-iot at lists.fi-ware.eu<mailto:fiware-iot at lists.fi-ware.eu>
Cc: Martin Bauer; ext Ricardo de las Heras
Subject: RE: [Fiware-iot] Feedback Thing Management Architecture

Hi all,

   I checked the architecture in-depth and I'm sharing Martin's concerns.


-          The Observation Handler, Publish/Subscribe Broker and the Events Repository is already present in the Data Handling GE on the gateway level. When working with IoT devices, the same components need to be present on the backend as well. Ricardo, can you clarify if you included these parts in your slides because you needed to show the connection between Data Handling and Resource Management, or you wanted to take over Data Handling functionality?
                No :), I didn't want to take over of components out of the T5.2 scope, simply Data Handling, P/S/N Broker etc. are showed there for a better understanding of the slides and to put in context the different interfaces and interactions with the rest of the task within WP5.

-          Thing-level actuation is not present on the slides, but they seem to be simply left out. I think we can iterate on including it.
Best,
Dénes


From: fiware-iot-bounces at lists.fi-ware.eu<mailto:fiware-iot-bounces at lists.fi-ware.eu> [mailto:fiware-iot-bounces at lists.fi-ware.eu]<mailto:[mailto:fiware-iot-bounces at lists.fi-ware.eu]> On Behalf Of ext Martin Bauer
Sent: Wednesday, January 11, 2012 9:33 AM
To: fiware-iot at lists.fi-ware.eu<mailto:fiware-iot at lists.fi-ware.eu>
Subject: [Fiware-iot] Feedback Thing Management Architecture

Hi all,

We at NEC have started to look into the Thing Management Architecture proposal made by Telefonica. Up to now we had assumed (also from the high-level architecture document) that the architecture would be closer to IoT-A/SENSEI.

I'm not sure why you assume that, for me is only a global reference architecture for the IoT world, this world would include IoT-A and Sensei as well, why not.

We see a number of open questions and points that we would like to start discussing:


-          Scope of the proposal and relation to other tasks in the WP
We have the impression that the proposal provides a certain functionality in a stand-alone fashion.
How does the proposal relate to the other tasks, in particular T5.3 and T5.4?
Is it correct to say that the proposal covers significant parts of data handling (T5.3) in that it gets the update events, stores them in the repository and dispatches them further?

My clarification for this question Martin is that the last slide shows GE blocks that clearly represent significant parts coming from other tasks and even wps (as wp6), like Publish Subscribe broker and the Observation Handler. Even the events repository could represent the interaction with the massive data storage GE coming from WP6 if needed, it would depend on the system requirements
Those enablers are out of the scope of T5.2 but will fully support the Resource Management needs.



-          NGSI-related questions
The idea of the NGSI interfaces is that they define the external interfaces of a "context enabler". They do not define the internal aspects, i.e. the architecture, underlying concepts etc. of such a "context enabler". The NGSI-10 interface is primarily intended for applications that use "context information", whereas NGSI-9 is intended for the interaction of the "context enabler" with peers or external context sources. They may provide context information which can be used by the "context enabler" to answer requests sent via NGSI-10. The peers or external context sources would typically implement NGSI-10 for accessing this context information.

We are not sure whether the use of NGS-9 in the proposal is used as intended. You identify missing functionality, but we think that this functionality is related to the internal structure of the system, i.e., IoT Resources are aspects of the internal structure and this concept does not exist in OMA-NGSI
and does also not fit the intended use.

As you say, some of these operations are not supported in OMA NGSI-9 so we will have to define an API which would also be exported by the "Things/Resources Configuration Management" component.   So, my point of view is that those extensions would fit in the OMA-NGSI extension, indeed we can provide later those extension to OMA suggesting their inclusion in the standard.
Anyway a question to analyze is whether we should go for extending NGSI-9 and fast-track results of such extension to OMA.



-          General architectural concerns
>From our point of view, the proposal can be characterized as a (logically) centralized architecture that is founded on a complete decoupling between applications and IoT resources, i.e. requests from applications cannot have any direct effects on the IoT resources as the latter publish their events independent of any request.

You say decoupling between Application and IoT resources, OK, I agree this point of view as well, this decoupling is in deed one of the principles followed in our IDAS architecture design.

The interaction type supported therefore is an asynchronous "push"-style M2M data transfer that does not allow any other interactions.

The resolution (unlike in IoT-A) only works from IoT-data to Things, but not the other way round, i.e., the IoT resources are not visible and therefore accessible to applications or IoT components from T5.3 and T5.4.

The upper applications layer directly interacts with Things and Resources, so I don't understand why you conceive that the Iot resources are not visible to applications.
Sorry if this concept is not clear enough in the picture, but the idea is that applications directly interact with both, Things Manager and Resource Management (through the named Basic Repository Management).

We currently do not see how Thing-based actuation can be supported in this approach as this required a resolution to IoT resources and then a direct interaction with these resources. (We also see use cases where queries should be directly forwarded to Iot Resources.)

Every Thing are described based on values that properties linked to Things take over time (resources' capabilities), so you wouldn't need necessarily direct interaction with its associated resources .

Finally, the business processes/workflows planned in T5.4 require the Thing-based look-up/discovery of IoT Resources, which should then be directly
integrated into the process execution.

OK, right, and do you see in those slides any constraint for that? Discovery processes can be based also on Things with this model of architecture.


Best regards,

Martin and Tobias
 --
-------------------------------------------
Ricardo de las Heras
M2M Research Technological Specialist
E-mail:<mailto:rheras at tid.es> rheras at tid.es<mailto:rheras at tid.es>
Phone1: (+34) 983 367625
Phone2 OCS: (+34) 91 31 29511
Telefónica Digital<http://www.tid.es>
-------------------------------------------

________________________________
Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at.
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/old-fiware-iot/attachments/20120118/df02ccf7/attachment.html>