Y-sasaki: At least the earlier examples you mentioned were specific technologies that ultimately made specific contributions. The IoT is basically a broad generalized term -- a high concept. Many things will happen that can be categorized that way, but few will happen just because we started using the term IoT. (Also, I like your little green man icon!)
Bert: I'm with you on the IoT name. It's hype, imho. Most of the principles of the IoT were well-defined as part of the "Information Superhighway" in the late 1990s. Whether it's called the industrial internet, the internet of things, or whatever, it's still the Internet, isn't it?
I believe we are agreeing. People do seem to be obsessed with predicting the future no doubt in many cases for their corporate goals and really I don't blame them, we all want our competitive advantage.
It is that need to define the future that has lead to the stalling of base protocols for IOT I believe.
"Do we want/need different networking standards to implement specific real and perceived requirements of next generation networks? Yes. However, I see some standards move perhaps too far up the application space and when that happens while you can drive adoption in specific markets, you can also stunt progress and/or create effective fragmentation."
The way I would put is is that you cannot pre-define all of the standards that might be needed for the IoT, so-called. The printer example is a good one, because vendors will always come up with a printer that can do something new, or better, and will have to accommodate the new features in the message protocol to run that printer.
So, this has been going on forever, essentially. Printers are actually a decent example. Used to be they were connected via localized serial or parallel interfaces. Then they got onto Intranets, attached to boxes that translated your DECnet or Appletalk or IPX into the serial interface the printer wanted. (Note: very similar to a Modbus that morphs into Modbus over TCP/IP.) Then they started supporting a gozillion different fonts, paper sizes, enveloped, photographs, faxing, scanning, etc.
Who would have predicted what protocols would be required, 25 years ago? Why should we obsess that we can't predict the future now, on this topic thread?
The underlying network is defined ... which I said on my post. That underlying piece already fully exists for the IOT to implement today, right now.
All the other things you discussed, printer drivers, etc. are not defined by standards, but defined by printer companies, Microsoft, etc. They are not universally agreed upon defined standards but commercially implemented pieces of software.
Do we want/need different networking standards to implement specific real and perceived requirements of next generation networks? Yes. However, I see some standards move perhaps too far up the application space and when that happens while you can drive adoption in specific markets, you can also stunt progress and/or create effective fragmentation.
"Sure things plug into networking standards and my computer can talk to my printer, but my router does not."
Of course it does. We have all manner of Intranet connected printers throughout the enterprise, and anyone from coast to coast can send documents to any one of them. The messages go through routers, to the printers.
And to use those printers, any PC needs the appropriate drivers for that model of printer. You want your printer available to anyone on the Internet? That's easily done too. Its name gets into the public DNS, and you're done.
The stacks of different standards which exist today has been decreasing already, for decades, as the best ones survive. At the same time, anytime something new is networked, this new thing brings with it some specific needs. So that's a counterforce.
Sure things plug into networking standards and my computer can talk to my printer, but my router does not. Sure packets can be exchanged but there is no high level that says I am a printer and treat me in such a way, etc.
Ultimately what we have is stacks that and physical standards that allow communications, but much of what happens is defined by software that has no standards at all in many cases.
Is it wrong to believe that IOT will be any different?
Yes we need stacks and physical standards to allow communications but we need to be careful we do not go overboard defining interoperability lest we make meaningless standards that market forces just walk over or worse yet hinder progress.
Going back to the orginal article...YES it's a real issue. In communication platforms there are dominant and commonly adopted platforms which allow people to maximise the benfits of the existence of an internet connection anywhere and anytime: Facebook, Twitter, Google+.
The absolute mess of protocols, still hampers an easy equivalent integration of devices, sensors, data across platforms. It's the reason OpenRemote (founders Marc Fleury, Juha Lindfors) started an open source middleware, allowing the integration across verticals ("the standard is no standard"), adding cloud based vizuaisation tools, and running on standard hardware.
Intreaging to see how traditional companies, seem to think that choosing the right standard is critical, while they should focus on getting real value to their customer base...
"What I meant was there is not an interopera blke set of hardware and software choices available for people who build IoTs today."
But there are common protocols in use that can be converted into whatever you need to run over the backbone network, which may in turn be tied into the Internet (if it makes sense to do so).
Countless examples of this. For instance, for machinery, you might have legacy buses like BACnet, Modbus, Profibus, used to run stuff in factories or in other venues. All of these legacy buses can be tied into an Internet backbone. In many cases, those old protocols are actually layered over TCP/IP or UDP/IP, as a quick way to link these devices into intranets.
Is there a reason why a particular intranet like that should be made available on the Internet? Well, usually not, unless tunneled over secure long distance links. But that's only because the people who run the operation don't want intruders in there. If there were such a need, there's nothing difficult about making these messages available to anyone on the Internet.
Same goes for the lights in your house. If you're so inclined, there are ways already out there to link up switches into an intranet, and ultimately, if you wish, the Internet. There's nothing new that MUST be invented, unless you want to create a more standardized and coherent set of protocols to displace all the ones already in existence.
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.