tag:blogger.com,1999:blog-4717591499307449402.post2149342461186191935..comments2018-10-04T09:15:36.674-07:00Comments on Data models for the Internet of Things : The Internet of Things needs an Open Infrastructuremjkhttp://www.blogger.com/profile/03377871670289947061noreply@blogger.comBlogger9125tag:blogger.com,1999:blog-4717591499307449402.post-49737727327751482542013-01-22T06:18:58.427-08:002013-01-22T06:18:58.427-08:00Hello Michel,
I actually know one company and the...Hello Michel, <br />I actually know one company and their startup that works with open infrastucture. It's polish companny from Wrocław that started in 2012. It is only a landing page, but you may read something about the project there: http://www.cloudyourcar.comCarp_in_skyhttps://www.blogger.com/profile/01291528265503079676noreply@blogger.comtag:blogger.com,1999:blog-4717591499307449402.post-3277769998292912992013-01-21T12:59:18.410-08:002013-01-21T12:59:18.410-08:00@Paul, thanks for the pointer to an Open Source ET...@Paul, thanks for the pointer to an Open Source ETSI M2M framework. I'm very interested in working with existing Open Source frameworks to integrate the Smart Object API. Yes, OSGi is not required in the ETSI spec. mjkhttps://www.blogger.com/profile/03377871670289947061noreply@blogger.comtag:blogger.com,1999:blog-4717591499307449402.post-51516042194753047882013-01-11T13:20:02.035-08:002013-01-11T13:20:02.035-08:00@Michael, thanks for the reply. I certainly think ...@Michael, thanks for the reply. I certainly think a wiki would be useful.<br /><br />As for the ETSI M2M standardization work, it is in fact a REST API specification and not bound to any particular implementation technology, OSGi or otherwise. I was not aware of the Ericsson reference implementation, I will check this. The only implementation that I was aware of is "Cocoon" by a company called Actility and the source code is open n this project.Paulhttps://www.blogger.com/profile/11884094081271509890noreply@blogger.comtag:blogger.com,1999:blog-4717591499307449402.post-68824893284020948712013-01-11T11:20:11.167-08:002013-01-11T11:20:11.167-08:00@Paul, thanks for the comment.
I am active in th...@Paul, thanks for the comment. <br /><br />I am active in the IOT-A (EC Internet of Things Architecture) community, as a stakeholder in the Architecture Reference Model (ARM). pls refer to the December IOT-A newsletter for more info.<br /><br />As for the ETSI standard, it is certainly an open standard freely available. The ETSI gateway allows a mix of open source and proprietary code to be integrated in a system through OSGi. The reference implementation (Ericsson) contains some open source and some proprietary bundles. It looks like the IPV6 stuff support is Open Source, but some key GE bundles still not available in open source to enable actually building a free gateway as far as I know.<br /><br />I could make a list but NB it will end up being a ranking because there are varying "degrees" of open-ness among almost everything out there. I am first working on collecting a good list of the open source (open licence, e.g. GPL or Apache) IoT software that exists today. There is a surprising large number of open source IoT projects just on Github and Google code.<br /><br />We're looking for ways to enable more public participation. An open source IoT project wiki would allow a big list to be constructed and branches to be maintained for projects.<br /><br />mjkhttps://www.blogger.com/profile/03377871670289947061noreply@blogger.comtag:blogger.com,1999:blog-4717591499307449402.post-85455109382591986342013-01-11T09:03:47.768-08:002013-01-11T09:03:47.768-08:00Hi Michael,
re: "In Europe, there is a broad ...Hi Michael,<br />re: "In Europe, there is a broad consortium of Industry, government, and educational institutions working with standards bodies to develop a comprehensive framework for the IoT..."<br /><br />Are you referring to the recently published ETSI M2M Communications Standard? If not, could you please provide a short list of other standardization works in progress in this field?<br /><br />Regards,<br />PaulPaulhttps://www.blogger.com/profile/11884094081271509890noreply@blogger.comtag:blogger.com,1999:blog-4717591499307449402.post-1324859596404918722013-01-07T09:17:19.019-08:002013-01-07T09:17:19.019-08:00Christophe, I completely appreciate your point. Ho...Christophe, I completely appreciate your point. However, using a graph for more complex and supervisory functions does not exclude low order cases being integrated into a single device or simple device-to-device connection. It's just a simpler graph. <br /><br />Take the thermostat example. There's nothing to prevent a smart thermostat from being a simple integrated device that has optional remote control capability for the second order case. Then we can run the local second order control from the gateway. We can add third order, etc. using the internet which can further optimize the heat bill but doesn't leave us cold (or hot) when the internet connection glitches.<br /><br />We can also overlay graphs so that there are multiple redundant paths to getting something accomplished. If one path fails, another will continue to provide control. More sophisticated voting e.g. PAXOS schemes can be imagined for really critical applications. <br /><br />I believe in Moore's law and imagine richer devices, sensors and particularly actuators, will become more commonplace as well as devices that simply interact with each other without needing external gateways, using some local association mechanism like NFC, etc. to discover each other.<br />mjkhttps://www.blogger.com/profile/03377871670289947061noreply@blogger.comtag:blogger.com,1999:blog-4717591499307449402.post-44981328977147131432013-01-07T06:48:52.296-08:002013-01-07T06:48:52.296-08:00And then comes ... "distributed intelligence&...And then comes ... "distributed intelligence". I've seen many architectures applying/promoting this "separation of functions" between dumb sensors, intelligent workhorses and dumb actuators. It's what I call "the Firmata way". Personally I date to question its soundness, because it looks very unreliable to me.<br /><br />Let's take the proverbial "thermostat" example. The "integrated" version is a temp sensor + contact (whether full analog/mechanical or electronic doesn't matter here), and the "firmata" version is a temp sensor(+network), a "master" of some kind(+network) and an "actuator" of some kind(+network).<br /><br />Now when the network is down, so is your heating. Even worse, when the "master" is down, so is your heating.<br /><br />I may sound harsh, but to me there is a more important problem than the smartphone / light bulb : the "zero-order problem", that means you should not rely on failable systems. <br /><br />Hence, my statement is that a "simple graph" representation is absolutely inadequate to represent the problem at hand, because it doesn't integrate the zero-order, first-order, second-order etc. problems.<br /><br />An example of second order problem is when my heating system gets influenced by weather predictions for example. I know it will be sunny today, hence I know my (passive) house will need less fossile energy to be heated.Christophehttps://www.blogger.com/profile/15344789388370172175noreply@blogger.comtag:blogger.com,1999:blog-4717591499307449402.post-25600812977565692602013-01-04T15:45:49.961-08:002013-01-04T15:45:49.961-08:00Hi Chris,
Thanks for the comments.
My simple gra...Hi Chris,<br /><br />Thanks for the comments.<br /><br />My simple graph is just to illustrate the first order problem, that there's more to the IoT than a smartphone controlling a light bulb.<br /><br />The actuator feedback issue is interesting, because it's not obvious that notification should be a semantic and routing inverse of the path taken to actuation, as well as some practical graph traceback questions. <br /><br />You're pointing out a bigger issue when it comes to the metadata. Obviously the metadata makes the graph, but exactly how the description leads to discovery and linkage, and how property updates are propagated along links will need to be worked out and done in standard ways for practical interoperability. <br /><br />Two big items needed in the platform, above the basic API, are the ontologies and the high level patterns used to create and maintain the graphs. mjkhttps://www.blogger.com/profile/03377871670289947061noreply@blogger.comtag:blogger.com,1999:blog-4717591499307449402.post-17031568553585078872013-01-04T14:45:50.236-08:002013-01-04T14:45:50.236-08:00Michael, I'm not sure that the graph you provi...Michael, I'm not sure that the graph you provided is quite complete yet. IMO there are at least two missing elements: 1) actuators need a reply flow back to the services/logic to report success/error/fault status 2) to make the whole M2M thing work the concept of meta data needs to formalized and its place in the graph depicted. The meta data I am referring to is that required for a consumer to understand what a source device is and what its data elements are and what they mean. How this mechanism works will be a critical part of making M2M better than it is now.<br />Anonymoushttps://www.blogger.com/profile/15064111675824881778noreply@blogger.com