And that's only scratching the surface. Imagine all the software and data integration challenges that have grown exponentially with the new healthcare law. EMR will be pretty ineffective if one proprietary system can't read what another proprietary system is saying -- even if the hardware technology makes them compatible.
Prabhakar - your suggestion of standard set of high level commands is in line with what Kang Lee from NIST was trying to accomplish with IEEE1451 - but this approach has not been widely adopted.
tshefler's point that a more flexible protocol may be needed as per IETF precedents, or any of the http RESTFUL services.
bert's approach to take each new feature set independently is certainly how we get to defining new standards/best practices, .
Rick's article on "US Consortium Forming on Industrial Internet;" Rick Merritt; 8/7/201 identifies industry partners, led by GE who, working with NIST, have identified a wide range of IoT areas requiring specifications including:
Co-engineering cyber and physical systems
Identifying cyber-security issues and solutions
Addressing concerns about interoperability
Identifying ways to maintain robust wireless connections
Setting standards for real-time data collection and analytics
This year White House Fellows Sokwoo Rhee, the founder of Millennial Networks, an early IoT startup spun out of MIT; and Geoff Mulligan, the head of the IPSO Alliance, certainly bring unique capabilities to this general problem area, although it is hard to imagine a single group tackling such diverse issues.
It will be interesting to see how this Industrial Internet US consortium is formed, what role there will be for international partners, and how individuals and companies can contribute.
In the interim, as has been suggested by some of the commenters, there is a multiplicity of forums including MIT consortia, for convening suppliers, customers and designers around a common set of requirements.
The IOT protocols I have look at read like wire-level protocols defined by Electrical Engineers. I think that for better interoperability, IOT protocols need to be forumulated in such a way that they carry the required information but afford flexibility. IOT protocols may need to be managed by the IETF for this to happen.
Sometimes, if you really have to get something accomplished, you simply make it happen. The idea of IoT, if it is assumed to be something brand new (which I don't think is the case), can make people think that, f'rinstance, you sprinkle dozens or hundreds of sensors throughout a facility, they auto-identify themselves, they automatically determine their location, and magically any computer on that net will be running monitoring and diagnostic software to give any operator a clear picture of ... something or other.
But really, this stuff has been happening for decades. The practical solution is that the designer of the system knows ahead of time where these sensors (or other devices, btw, we're not just talking about sensors) are located, each sensor or other device is uniquely identified to the network, and software provided in the applicable computers montitors and controls these devices as needed, for that particular system in that particular venue.
It's always good to be striving for more plug and play standardization. And I'm sure it's going to happen, via untold number of industry groups and conferences. However the problem with this idea that "you just turn it on and it works" is that these IoT systems are solving oodles of different problems. Not just one or a few.
For example, since hospitals were mentioned, all hospitals are not the same. The machinery in them is not the same. What has to be monitored remotely and controlled remotely is not going to be the same. And with each new medical device, say a new design MRI machine, will natrurally come new features and new parameters to be measured or controlled. So I tackle these problems a lot more on a case by case basis.
In my opinion , if all sensors ,irrespective of their make, are required to communicate with a standard set of high level commands such as the AT command set for modems , the world of IoT will become more manageable. These commands could be formulated based upon the parameters that the sensors are measuring . these parameters could be temperature, pressure, humidity, weight, location co-ordinates etc The AT like command set will then become a high level interface for all the sensors interconnected
NASA's Orion Flight Software Production Systems Manager Darrel G. Raines joins Planet Analog Editor Steve Taranovich and Embedded.com Editor Max Maxfield to talk about embedded flight software used in Orion Spacecraft, part of NASA's Mars mission. Live radio show and live chat. Get your questions ready.
Brought to you by