From a security point of view, it's probably smart to assume that your network is accessible from the outside. But from a practical point of view, interoperability of INTRAnets of Things seems like something purist hackers want and not industry. If you are an enterprise, the data, the apps you create, and things, machines and sensors you hook up are proprietary. It's not a fair comparison to say Things should be like websites. It's more apt to say connected things are like resources in your private network.
I'm coming at this from the same perspective as gdilla. In the end, the mesh networks connect to the Internet, so why do they all need to operate in the same way? Each app will have its different requiremens. For instance, some will need to focus on extremely low power, some may need more emphasis on security. Why not let these apps drive their individual protocols, and then fly the end data or queries over the Internet?
Better said than I! And companies can publish their APIs/SDK on managed services like Mashery and the like if they really care about letting people mash things up (or just for their own third party partners).
It all depends on the scalability of the solution. If you trace the history of networking there were a number of protocols that were designed for local network segments because there would be no reason for the data to go any further than that. Novell, DECnet, Microsoft networking, and innumerable others were built to scale only to the size of at most a medium-sized corporate network. When TCP/IP came along it swept all of these aside because it was a truly scalable and uniform solution.
Many companies would argue that sensor networks are different, that the information should be limited to strictly local networks, but I sat in too many meetings in the '80s and '90s where the same class of people made the same arguments about their internal networks and came to the conclusion that they didn't really need this newfangled "Internet" thingy.
@gdilla: I didn't mean to suggest that all IoTs need to talk to all other IoTs.
What I meant was there is not an interopera blke set of hardware and software choices available for people who build IoTs today.
You could, for example, build a nice Zigbee net today. But later if you decide you like the features of the 6WLowPAN products you are stuck with needing to forgo them or rip out the old Zigbee net or create a homegfrown bridge.
This is just one scenario where the lack of interoperability and standards raises its head. There are probably as many scenarios where tis comes up as there are deplyments.
I don't share the enthusiasm of many on this thread that IoT networks will just need to be connected...I think the IoT space is a total mess right now, and nothing really can be networked effectively as is...lots of work on standarization is required...I am not planning to re-boot my thermostats and my freezer every second day like my PC, nor I am planning to become IoT home network specialist to resolve all networking conflicts that will arise once my garage door opener starts taking to my gardening hose ;-)
I think IoT/M2m always will live on different networks and protocols and that we have to live with that. What we need are models and interfaces, I would like to call them abstractions, for things over different protocols to be able to talk to each other.
The situation we are at at the moment is much like how PC software development was carried out before windows arrived. We at that time made a small program that fitted well on one diskette and to be able to sell this program we had to supply maybe ten or twenty times the diskettes for hardware drivers for different printers, screens, keyboards, etc etc. The hardware abstracion layer in Windows all changed that with the boom in software revenue that followed.
So what we need is the abstractions also for m2m/IoT. VSCP (http://vscp.org) presents one such model (no its not just a protocol) it's a framework. And it solves some common problems
1.) A uniform way to discover devices. 2.) A uniform way to configure devices. 3.) A uniform way to present data from devices. 4.) A uniform way to update firmware in devices.
Never mind who made the hardware, who owns the presentation surface or what protocol that is used. IMHO all discussions on which protocol is the killer protocol is of no interest the points above must be solved and are the key to the successful growth of m2m/IoT.
Blog Doing Math in FPGAs Tom Burke 14 comments For a recent project, I explored doing "real" (that is, non-integer) math on a Spartan 3 FPGA. FPGAs, by their nature, do integer math. That is, there's no floating-point ...