Hi, Please find responses to your questions below. As mentioned in a previous email, they just complement or elaborates answers provided by Ricardo a bit further. On 11/01/12 15:58, 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? Actually, the Configuration Repository is able to resolve what are the relationships between IoT resources and Things and between Things themselves. There are two aspects related to this: * Whether that information always map to records in the repository is subject to implementation. We foreseen that there may be relationships that will not be stored but be inferred and returned on-demand, in response to queries made by the application. It would be, as always, a trade-off between limit in storage and performance in time response. * There will be relationships that will be registered explicitly or can be inferred. The former are registered through a well-defined API. The later are derived by the Inference Engine. Again, based on the previous point, whether this second "inferred" relationships are stored in the Repository to improve response in discovery requests is subject to the particular implementation. Note also that when the Inference Engine actually "infers" a given relationship may vary on implementations. It may just perform those inferences whenever a discovery function is invoked or the Inference Engine may be kind of a Production System running on the background and creating the relationship records in the Configuration Repository whenever a relationship is inferred (e.g., the creation of a new entity, and the existence of rules that establish how entities of that type relate to other type of entities that may already exist, lead to creation of relationships in the configuration) - 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? It would be able to handle rules that enable to infer how relationships between entities can be inferred or become out of date. We envision that the Inference Engine should support an API for creating/modifying/deleting rules. - Although previously I mentioned that there is an Event Store in Data Handling, it is still curious who accesses it? The Event Storage, which is different from the Configuration Repository, was illustrated in the picture in order to explain how the different GEs could work together. - Why is the Portal component within IoT? Is it part of the backend? At the end of the day, the FI-WARE testbed should be able to support a portal that will ease setup and configuration of a given IoT space. Many of the functions exported by the Configuration Repository should be accessible through the portal, enabling endusers or administrators to interact with the system. - 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? Registration of entities (either Resources or Things) could be made by the application or the portal (essentially through the same set of APIs which would include NGSI-9). Registration of IoT resources, in addition, could be made from the south layer, using whatever southbound API we support (e.g., ETSI M2M). Registration of IoT resources from the southbound may trigger actions in the Inference Engine that lead to inference about existence of a new virtual Things (this to be based on established rules). Registration of IoT resources from the southbound may also become visible to applications or endusers who are able, in turn, to determine that a new virtual Thing should be registered in the system. - 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? I'm not sure I get this question, but maybe it's a matter of naming. I believe that the functions of the previously named "Services and Resources Interaction GE" are assumed by one or several of the components in the picture. Note that the proposed pictures elaborates further on how the Architecture of the GEs dealing with Management of Configuration Info may look like. It may supersede previous descriptions. - 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. As explained, integration with actuactions was simply not elaborated as integration with data handling was. It is just a matter of elaborating that aspect. It shouldn't be that difficult. Hope it helps, -- Juanjo 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. 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: 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? - 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. 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? - 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. - 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. 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. 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.) 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. Best regards, Martin and Tobias ------------------------------------------ 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 ________________________________ 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/20120123/cdc19a40/attachment.html>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy