If the skillset of embedded engineers is the speed bump in developing next-generation embedded devices, then they need to either retrain or get out of the way. I have long said that embedded systems is developing a real application layer, particularly when you have powerful 32/64 bit computing capability, full operating systems, now networking. Back in the day of the Internet toaster I was very skeptical of most embedded network devices because the infrastructure simply was not there to support them, but that is no longer the case. Embedded teams creating IoT devices should include application-level engineers that can professionally take advantage of that power.
I don't think the problem is skillset of embedded engineers...the problem is definition of the problems they are asked to solve...checking my fridge whether the milk is going bad is not useful...connecting trillions of sensors to predict weather locally is...we just solve the wrong problems
I'm kind of with Kris on this. The problem is, it seems like everyone is saying something or other about this IoT, but no one is defining what THEY mean by the term. You need to get specific enough about A problem you want to solve, before you can say anything intelligent about this amorphous concept IoT.
Let's say you feel the urge to know the temperature of every item in your refrigerator at home, even while you're somewhere else. That's not so difficult to do. You furnish each smart refrigerator with a gaggle of probes to poke into or wrap around every item, hardwire the probes to a central processor in the refrigerator, have that refrigerator processor request an IP address from your home modem/gateway via DHCP, build a web server in that processor, and now the owner can access his refrigerator from anywhere, with a standard web browser. (You probably have to dedicate a TCP port in the NAT, if using IPv4, but even that's a well-known technique by now.) Perhaps in Version 2, you use Bluetooth to connect each probe to the refrigerator processor.
There. You don't need any new industry-wide standards for that problem. All the standards you need exist already, and every refrigerator manufacturer is free to organize his own refrigerator web site as he pleases. But that's AN example. There are countless ways you can use a global network to provide access to gizmos. And too, just because something CAN be done doesn't mean it needs to be done.
The refrigirator case is simple: there's plenty of power , plenty of space, cost is not so constrained(maybe),
Let's talk about something different. A connected tooth brush that due(maybe connection for the dentist is important) to some reason you really need for it to be connected to the internet , not just to a smartphone. And you want it to have an easy to use API because all kinds of interesting apps could be developed , and you want other companies which are better than your hardware company in things like health,behaviour change and gaming. And it's very price sensitive.
Since it's power limited, you have to optimize yoour communication protocol. WIFI isn't good enough. Bluetooth isn't good enough because you need direct net connection. What do you use ? you can use zigbee but then you need some server.more money. It's possible , but not ideal.
I get your more general point, but as to this toothbrush, not so difficult really. Electric toothbrushes out there today sit on a charger dock, which plugs into the bathroom electrical outlet. So the problem is much like the refrigerator. You build the smarts into the charger pod thing, and then that can access the toothbrush via something like Bluetooth.
Yes, the easy approach now is HTTP, in large part because it avoids the user, or the dentist in your example, having to install anything new in his PC or handheld.
But really, this is my point. I keep seeing articles that try to make broad brush general statements about "the IoT." The problem is, you can't. A whole lot of IoT applications would not require anything new or revolutionary at all.
Bert, that is the kind of implementation that I saw in many of the Internet toaster generation. There are problems with it, though. It will display on a website, but the data would be hard to extract and use. These implementations need data that is self-describing and interpretable by computers instead of people. Let's change the problem a little. Let's say that the refrigerator manufacturer wants to collect the information to make sure that their products are working. They would want to collect the information from hundreds of devices and run statistical analyses on the data. They might put out version 1.0 of this and start getting data. Then they might realize that it would be useful to collect diagnostic information as well. Version 2.0 would add this capability, but they would still want to collect from the V1 devices. This would be a good reason to tag the data with a version number. They might use HTTP to transfer the data, but another protocol may be more desirable - for example, they might use SSH to log into the device and trigger diagnostics or otherwise interact directly. All of these things can be done using standard protocols, but a standard for the data format would enable allow the same information to be collected across all refrigerators, even if they used different versions of the standard. Many industries have defined XML schemas for things like this, allowing data exchanges to take place. You are correct that standards should be used, but there is also room to create specialized standards across industries or other groups. This can also be done in a proprietary fashion, but that creates islands of data that make things more difficult.
IoT is the Next Big Thing. PCs are in negative growth and smart phones are hitting saturation, so chip-makers need the Next Big Thing so they can sell Lots of Chips. IoT is that Next Big Thing. Trying to define it more specifically than that is beyond the scope of engineering :-)
It's kind of like the history of Artificial Intelligence. Nobody can really define intelligence in any intelligent way. Indeed, Edsger Dijkstra is quoted as saying: "the question of whether machines can think is about as relevant as the question of whether submarines can swim." So the practical definition of Artificial Intelligence was "whatever the DoD is funding this year that's being called AI". Basically, once a mysterious "intelligent" algorithm is understood, it ceases to be intelligence and becomes Mere Automation. OTOH, everybody understands what it means to be funded.
For those who missed it the first dozen times I said this, when I first heard about IoT at a recent ARM TechCon, it took me about five minutes to change IoT into "Internet of Digital Things", or IDioT. I'm going to have fun playing with the many "IoT" chips that will come out since they'll give me cheap computing and connectivity, but as far as end products are concerned I think I'll wait for the next Next Big Thing :-)
Drones are, in essence, flying autonomous vehicles. Pros and cons surrounding drones today might well foreshadow the debate over the development of self-driving cars. In the context of a strongly regulated aviation industry, "self-flying" drones pose a fresh challenge. How safe is it to fly drones in different environments? Should drones be required for visual line of sight – as are piloted airplanes? Join EE Times' Junko Yoshida as she moderates a panel of drone experts.