Revision history [back]

Hi,

thanks for asking the question and giving us the opportunity to discuss some of the advancements provided by FIWARE.

Let me go to the issues your raised and your arguments. Then I try to point out the advantages of FIWARE.

(a) Hardware Heterogeneity Problem I agree that one on the issues to solve is hardware heterogeneity. There are other ranging from global identifier, discovery, fast control loops, Cloud mashups, large scale distribution, scaling to Billion of Objects - just to name a few.

(b) Existing Systems You mention lot's of different systems ranging from BACnet/WS to 6LowPAN. I think you will agree that they are NOT doing all the same. And that they in many cases created for a specific use and a specific deployment. The amount of different systems shows basically how old M2M is actually.

Example 6LowPAN: target is to have a IP layer on top of a low-bitrate wireless network. It is optimized for compressing IPv6 in a few bytes. While good for its special use case, I doubt that it makes sense to use it with a wired infrastrucutre or over a 3G/4G/5G network. I don't think it is suitable in an Cloud environment, for integrating IoT into the Internet-of-Services, or other aspects.

(c) Similar problems in a total different areas Let me point you to another area in which we have a similar observation - many (legacy) systems, no agreement on a single one. I am talking about programming languages. But you can replace it with OS, databases, ... There are thousands programming languages out there. Some obscure, some useful, some outdated, some specialized. Some of the real important new ones came with real important advancements in the understanding of programming, in having ideas how to avoid common errors, or on how to do support libraries right. - C was born to have something better then Assembler. - Pascal was invented to show the quality of structured programming. - Java was doing object-oriented programmin in a (still) procedural environment right (or maybe just better ?) and also improved a lot stability and to some extend protability

So at the end, they are not all born equal. They are created for specific purposes with a specific target environment in mind.

So why are some more successful then others? Maybe because they do a few things better then their competition, maybe they simply spotted a change in the typical usage environment faster then others and provide respective abstraction. They win, because the provide additional value to the programer, e.g. by being more productive or by easier solving specific aspects. Java was really a step forward for the Internet. Simple concepts as namespace bound to DNS domains helped to isolated the development effort from many people so that the resulting code could be much easier integrated without big renaming.

By now I hopefully have established that concrete system are solving problems they are designed for, and that in a changing world new system might be able to deal with new the new problems better. Let me check thsi for some of the systems you mentioned.

(d) Gateway / Networks The products you are mentioning are mostly gateway products, ment to be running on a single machine or on a small set of machines in the same network (e.g. UPnP). Usually a local area network or a M2M area network is assumed omn the device side of the GW. Gateway and devices are within single administrativ domain. In many cases IoT device are connected over an IoT/M2M area network, the applciations are residing on the gateway or at a specific server/Cloud in the network.

(e) Concepts Conceptual the mentioned system come with simple data models. Or some domain specific data models

Namespace and translation concepts are only thought of in the context of single gateways, usually a name relative to the DNS name of the gateway. This makes it difficult to deal with objects that are connected to two or more gateways. Larger IoT system in the Future Internt might have lots of heterogeneous sub-systems for importing data from many different systems. Take OpenHAB as an example, it is clearly ment for a single gateway. YOu can use another protocol, e.g. MQTT to bind multiple OpenHAB instances together, but there is no unifield system model, no single namespace, etc. etc. Interconnect has to be programmed by hand.

Discovery is usually of the semantic: "give me all objects which matches a given criteria". This might be okay for a gatgeway with a few hundred or thousand objects.

By now, I have pointed out some of the limitations of the mentioned systems. Let's move to FIWARE.

(f) Future Internet Requirements When designing FIWARE it was clear we are targetting a Future Internet szenario. It was clear from the beginning that this will be a kind of European Cloud, but with many different provider (not a single Google/Apple/Amazon/xxx Cloud). It was clear that data need to be made available across many different instances without even thinking which of the gateway was providing the translation services. It was clear that we target a world-wide system in which data can be provided on one side of the world and used on the other.

(g) IoT ARM IoT-A together with the IoT Forum has defined the IoT Architectural Reference Model (IoT-ARM). The ARM contained many concepts that are nor proving to be good concepts for IoT. For example, - a strict separation of devices and things(aka entities), something many of the above mentioned system do not have. - a flexible association between devices and things, which could be 1:1, but in many cases are 1:n - id's independent of the access path and not relative to gateways - separation of attribute value and meta-data (look at the existing system in many cases this is so mixed together) - discovery functions which are NOT discovery the complete world but can be scoped - strong typing (ideally referencing to an ontology) of entities, attributes, meta-data

(h) More concretly: advanced concepts / abstractions "Emphasize Things then devices" - you see the context entities are the core data elements and the describe usually things, not devices. "Harmonization across enablers/ecosystem approach" - instead of having an IoT data format only useful for IoT aspects, we agreed across many different enablers on the same data formats making plug&play between GEs possible. See Context and data management see storage... "query/subscriptions on thing level, not towards devices" - in FIWARE you query entities or suscribe to their information independent from where the information is coming, indpendent from which gateway conntect to the respective device "Distributed query/subscribe model" - queries and subscriptions are evaluated across many devices (note: not all brokers support distributed evaluations) "True hourglass model" - many legacy systems have more a pyramid model in which data is only flowing ot the top of the pyramid, consumed by a few applicatiosn there. FIWARE has a hourglass model in which a common wrist (NGSI data model, NGSI API) enabling isolation of the lower layers (which IoT devices) and the higher layer (which application). As a result, both sides can independenlty develop /* yes, many systems claim that as well, but have you seen a growing App eco-system on top of one of the systems mentioned.

"Composition" - with release 4 and 5 you will see build in mechanism for composing virtual entities from existing entities or directly from associated IoT data sources "Event Processing" - Compley Event Processing (CPE) directly integrated with NGSI events.

(i) Practical Advantages Besides the mentioned concepts and abstractions, FIWARE has already - REST API for easy use in the Cloud - many smart cities using the platofrom for publishing data - many startups using the generic enablers - a growing set of GEs working together and providing services - real product integration (e.g. the NEC gateway product leafengine is integrated into IoT Broker) - support/integration of important standards like oneM2M

Concluding: I have explained you that FIWARE is targetting a different szenario (Future Internet) then some of the mentioned systems. Would you use e.g. OpenHAB to integrate traffic information and CO2 information across a City? I have explained that FIWARE implemented some advanced concepts and abstractions that will support the mentioend szenario better. I have explained that FIWARE has some very practical aspects, like unification across many enablers,

I hope that gave food for thought. I don't think it will eliminate the pain expressed with the too many integration frameworks, but I do hope that I ahve explained where FIWARE has tried to introduce new concepts which makes dealing with IoT (especialyl on large scale) easier.

Feel free to fiore further questions...

Hi,

thanks for asking the question and giving us the opportunity to discuss some of the advancements provided by FIWARE.

Let me go to the issues your raised and your arguments. Then I try to point out the advantages of FIWARE.

(a) Hardware Heterogeneity Problem Problem
I agree that one on the issues to solve is hardware heterogeneity. There are other ranging from global identifier, discovery, fast control loops, Cloud mashups, large scale distribution, scaling to Billion of Objects - just to name a few.

(b) Existing Systems Systems
You mention lot's of different systems ranging from BACnet/WS to 6LowPAN. I think you will agree that they are NOT doing all the same. And that they in many cases created for a specific use and a specific deployment. The amount of different systems shows basically how old M2M is actually.

Example 6LowPAN: 6LowPAN: target is to have a IP layer on top of a low-bitrate wireless network. It is optimized for compressing IPv6 in a few bytes. While good for its special use case, I doubt that it makes sense to use it with a wired infrastrucutre or over a 3G/4G/5G network. I don't think it is suitable in an Cloud environment, for integrating IoT into the Internet-of-Services, or other aspects.

(c) Similar problems in a total different areas areas
Let me point you to another area in which we have a similar observation - many (legacy) systems, no agreement on a single one. I am talking about programming languages. languages. But you can replace it with OS, databases, ... There are thousands programming languages out there. Some obscure, some useful, some outdated, some specialized. Some of the real important new ones came with real important advancements in the understanding of programming, in having ideas how to avoid common errors, or on how to do support libraries right. - C was born to have something better then Assembler. - Pascal was invented to show the quality of structured programming. - Java was doing object-oriented programmin programming in a (still) procedural environment right (or maybe just better ?) and also improved a lot stability and to some extend protabilityportability

So at the end, they are not all born equal. They are created for specific purposes with a specific target environment in mind.

So why are some more successful then others? Maybe because they do a few things better then their competition, maybe they simply spotted a change in the typical usage environment faster then others and provide respective abstraction. They win, because the provide additional value to the programer, e.g. by being more productive or by easier solving specific aspects. Java was really a step forward for the Internet. Simple concepts as namespace bound to DNS domains helped to isolated the development effort from many people so that the resulting code could be much easier integrated without big renaming.

By now I hopefully have established that concrete system are solving problems they are designed for, and that in a changing world new system might be able to deal with new the new problems better. Let me check thsi this for some of the systems you mentioned.

(d) Gateway / Networks Networks
The products you are mentioning are mostly gateway products, ment to be running on a single machine or on a small set of machines in the same network (e.g. UPnP). Usually a local area network or a M2M area network is assumed omn the device side of the GW. Gateway and devices are within single administrativ domain. In many cases IoT device are connected over an IoT/M2M area network, the applciations are residing on the gateway or at a specific server/Cloud in the network.

(e) Concepts Concepts
Conceptual the mentioned system come with simple data models. Or some domain specific data models

Namespace and translation concepts are only thought of in the context of single gateways, usually a name relative to the DNS name of the gateway. This makes it difficult to deal with objects that are connected to two or more gateways. Larger IoT system in the Future Internt Internet might have lots of heterogeneous sub-systems for importing data from many different systems. Take OpenHAB as an example, it is clearly ment meant for a single gateway. YOu You can use another protocol, e.g. MQTT to bind multiple OpenHAB instances together, but there is no unifield unified system model, no single namespace, etc. etc. Interconnect has to be programmed by hand.

Discovery is usually of the semantic: "give me all objects which matches a given criteria". This might be okay for a gatgeway gateway with a few hundred or thousand objects.

By now, I have pointed out some of the limitations of the mentioned systems. Let's move to FIWARE.

(f) Future Internet Requirements Requirements
When designing FIWARE it was clear we are targetting targeting a Future Internet szenario. scenario. It was clear from the beginning that this will be a kind of European Cloud, but with many different provider (not a single Google/Apple/Amazon/xxx Cloud). It was clear that data need to be made available across many different instances without even thinking which of the gateway was providing the translation services. It was clear that we target a world-wide system in which data can be provided on one side of the world and used on the other.

(g) IoT ARM ARM
IoT-A together with the IoT Forum has defined the IoT Architectural Reference Model (IoT-ARM). The ARM contained many concepts that are nor proving to be good concepts for IoT. For example, - a strict separation of devices and things(aka entities), something many of the above mentioned system do not have. - a flexible association between devices and things, which could be 1:1, but in many cases are 1:n - id's independent of the access path and not relative to gateways - separation of attribute value and meta-data (look at the existing system in many cases this is so mixed together) - discovery functions which are NOT discovery the complete world but can be scoped - strong typing (ideally referencing to an ontology) of entities, attributes, meta-data

(h) More concretly: concrete: advanced concepts / abstractions abstractions
"Emphasize Things then devices" - you see the context entities are the core data elements and the describe usually things, not devices. "Harmonization across enablers/ecosystem approach" - instead of having an IoT data format only useful for IoT aspects, we agreed across many different enablers on the same data formats making plug&play between GEs possible. See Context and data management see storage... "query/subscriptions on thing level, not towards devices" - in FIWARE you query entities or suscribe subscribe to their information independent from where the information is coming, indpendent independent from which gateway conntect connteced to the respective device "Distributed query/subscribe model" - queries and subscriptions are evaluated across many devices (note: not all brokers support distributed evaluations) "True hourglass model" - many legacy systems have more a pyramid model in which data is only flowing ot to the top of the pyramid, consumed by a few applicatiosn applications there. FIWARE has a hourglass model in which a common wrist (NGSI data model, NGSI API) enabling isolation of the lower layers (which IoT devices) and the higher layer (which application). As a result, both sides can independenlty independently develop /* yes, many systems claim that as well, but have you seen a growing App eco-system on top of one of the systems mentioned.

"Composition" - with release 4 and 5 you will see build in mechanism for composing virtual entities from existing entities or directly from associated IoT data sources "Event Processing" - Compley Complex Event Processing (CPE) directly integrated with NGSI events.

(i) Practical Advantages Advantages
Besides the mentioned concepts and abstractions, FIWARE has already - REST API for easy use in the Cloud - many smart cities using the platofrom platform for publishing data - many startups using the generic enablers - a growing set of GEs working together and providing services - real product integration (e.g. the NEC gateway product leafengine is integrated into IoT Broker) - support/integration of important standards like oneM2M

Concluding: Concluding: I have explained you that FIWARE is targetting a different szenario (Future Internet) then some of the mentioned systems. Would you use e.g. OpenHAB to integrate traffic information and CO2 information across a City? I have explained that FIWARE implemented some advanced concepts and abstractions that will support the mentioend szenario mentioned scenario better. I have explained that FIWARE has some very practical aspects, like unification across many enablers,

I hope that gave food for thought. I don't think it will eliminate the pain expressed with the too many integration frameworks, but I do hope that I ahve have explained where FIWARE has tried to introduce new concepts which makes dealing with IoT (especialyl (especialy on large scale) easier.

Feel free to fiore fire further questions...