[Fiware-iot] Feedback Thing Management Architecture

[Bisztray, Denes (NSN - HU/Budapest)]

Hi All, 

 

I provide my feedback inline (I removed those parts that needs no further comment from my part): 

-          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.



Ok. So if I understand correctly, the Inference Engine continuously monitors the configuration repository, and when change happens it creates new rules? What about the Things/Resources Configuration management sends notifications when change occur, and then the Inference Engine evaluates if new rules need to be created?

-          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.

 

Ok, fair enough. 



-          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.

 

I have to confirm if we have to provide only an API or can work on a Portal as well.

-          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'.

 

Ok, lets put this to TODO. I think NEC needs derived resources as well, i.e. average temperature calculated (Tobias, can you confirm?).

 

-          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.

 

I just want to understand it. The question came from the perspective the Resource Directory (within Services and Resources Interaction) already contains a list of the resources / devices. The wiki says: "A repository storing all the registered Entites and Resources is needed as basic module for developing the rest of the services."

See: https://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FIWARE.Feature.IoT.ServicesAndResources.ResourcesDirectory.ResourceDirectory

This means to me that we already have a list of resources and devices. I found it redundant to have the same list stored in the configuration management. I obviously don't understand this, can you clear the picture for me?

 

 

        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.



It is fair to say that actuation may be part of Process Automation, but still, resource management has to provide support for it. I think this part will go to the GA.

 

Best

Dénes

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/old-fiware-iot/attachments/20120116/fecfdc9f/attachment.html>