One of the things I am most skeptical about for the future of IoT is that it's just REALLY hard to get the basics of networking, meshing, security, and updates down without an experienced and dedicated engineering team.
Realistically, Whirlpool just isn't going to be able to field that team to make their laundry machine resilient to malware attacks or a bricking update.
I always thought the only way forward with IoT was if it a big tech player offered an SDK / IoT platform that allowed developers to focus on the widgety part of their widget without having to think about the complexities of running an internet connected device. This seems like a big jump towards that.
There's the worry that your platform vendor is going to squeeze you for all your profit, harvest "your" data, use your data to bootstrap competitors (seems like X is profitable!), "cancel" your platform or all the other things they will definitely make sure they retain the ability to do.
"Pray we do not alter the Terms and Conditions further". Walled gardens, app stores and closed ecosystems are FAANG staples at this point.
I think in many cases the technical delivery risks (say, having crappy updates, janky apps and the odd CVE) seem more survivable than taking on those kinds of business risks.
When Blackberry bought QNX I thought they would leverage their carrier network footprint to build a security managed turnkey/white box IoT business in controllers from white goods to plant.
Everything I have since read about the major mobile hardware/phone companies taught me to stop over estimating the ability for organisations who are monomaniacally focussed on exploiting initial (fluke by statistical measures) in SF insights implemented by early engineering focus by arguably genius minds, have no ability whatsoever to understand how anything can interoperate or even coexist, because they are hell bent on protecting the boundaries of their product features and technology surface.
<Shameless plug> The company I work for, Particle [1] has set out to do exactly that, and we have built up quite the community of developers and enterprise customers who needed to solve this problem. Our founder started the business after trying to build an IoT product and realizing how much value there was in the common underpinnings of every IoT product.
Our offering comes down to three things:
1. Pre-certified hardware modules (open source [2]) that support WiFi or Cellular in a few form factors.
2. An on-device OS (also open source) that handles communication in the background and abstracts away the hardware using an Arduino-like API.
3. A cloud-based "command center" (closed source) that allows you to link up your backend services with events flowing to and from your devices via webhooks, manage over the air updates, and see connectivity metrics across your fleet. No data is stored - just ferried between your devices and the other end of the pipe that you configure.
Oh, and you can buy our devices off-the-shelf in small volumes and get them up and running in a few minutes!
> Realistically, Whirlpool just isn't going to be able to field that team to make their laundry machine resilient to malware attacks or a bricking update.
I think you're just using Whirlpool as an example, but they're not a great one. They have a fairly large IoT group that spans their entire ecosystem. (I'm a vendor in said ecosystem, and work with them on a weekly basis).
Your point is well taken, though: I work with many smaller companies on their IoT products, and they aren't in a position to manage their IoT projects.
> I always thought the only way forward with IoT was if it a big tech player offered an SDK / IoT platform
Yes, well hopefully not _a_ provider who will lock their customers into a proprietary platform. Hopefully many providers so manufacturers have options to choose from. Even better would be if there is an open standard, and then providers can compete on providing a better implementation.
The real problem is that everybody wants to be the rent seeker in the middle rather than the guy at the end trying to put a useful device together and make it earn money.
If I'm the guy at the end and I'm good enough to build the device, I don't need the rent-seeking guy in the middle.
If I need the guy in the middle, I, by definition, am not good enough to be the guy at the end building the device.
This mirrors what’s happened in banking and healthcare SaaS. You can be much smaller than Amazon and have a focused, compliant product with amazing customer lock in. But just like in banking and health records solid regulation in the IoT space needs to come first to force companies to the table.
You just described the reason most b2b SaaS vendors exist. Whirlpool will buy (and is buying) that which they cannot do in house and integrating it with their apps.
>I always thought the only way forward with IoT was if it a big tech player offered an SDK / IoT platform that allowed developers to focus on the widgety part of their widget without having to think about the complexities of running an internet connected device.
You would be amazed how many of the big players are doing exactly that. But I shouldn't talk about it any more, I work for one.
Washing machine manufacturers already focus on the washing part of the appliance without having to think about the complexities of running a water supply system.
It merely remains for IoT device management to achieve the same level of maturity as plumbing. Wait a couple of millennia, we'll get it right.
"We can solve any problem by introducing an extra level of indirection."
I'm extremely skeptical that this solves any particular problem other than for Amazon building devices, silicon vendors who want to be in Amazon devices. Which is fine, but the scope of this seems to be broader. It just doesn't sound like the right idea to me.
The biggest issue is the "common" part. You want to produce an api or abi common across OSs? How many chances do you have to get it right and not run into a web of api version bugs & issues? Who has made this successful in the past? UDI? (nope) And then you want a common api across an RTOS and Linux? Good luck.
Oh and by the way, where's the source code for this middleware?
I don't know why you wouldn't take the approach of making the underlying OS's easier to work with. If FreeRTOS is missing something, enhance it. If embedded Linux(s) are hard to integrate with, start an open source project to work on that problem.
I like the clear statement that the components are memory optimized (as opposed to execution-time optimized). Their target audience are device developers (and of course users of those devices), they're making good steps towards that, but of course both should be wary of how auditable the toolkit is, and most importantly can it be abused by Amazon
You do realize this toolkit is designed to deeply embed Alexa and other Amazon products into the device. So people WANT amazon to have a microphone and maybe a speaker and I'm sure lots of other metrics feeding back into an Amazon datacenter.
"Can" amazon, if they wanted, abuse this? It seems likely all the technical items are in place that they could. I don't see why they would, you are voluntarily putting everything they want into the device for them.
These IoT stacks like AWS greengrass (yes the marketing department smoked that day) or Azure IoT hub are missing something fundamental in my opinion : device management.
It would be nice if they could do stuff such as updating the Linux distribution.
The biggest hurdle I've found for updating Linux distros is that the chip vendor doesn't provide any newer Linux kernels. We're supporting some hardware right now that still runs 2.6.34 because that's the last kernel the chip vendor ported their driver patches too. And we will probably be supporting it for the next 5 or 6 years.
It's like a mini-OS layer that can be used to integrate Amazon's SDKs.
Basically it allows vendors to plug this low-level wrapper on top of their hardware's OS so they can easily add things like Alexa capabilities without writing their own API for that.
From what I understand, this is more or less what it does. It's like OpenWRT but for IoT devices and with the single purpose of integrating Amazon's SDKs in your hardware.
Please keep in mind that IoT is not just home device, but also machines in factories, utilities and so on. Amazon already has an offering for those devices at https://aws.amazon.com/iot-core and the machine learning and AI support to back it up. This allows them to better compete with players such as Siemens and GE in that area.
Betting that Amazon is using this big-time to provision devices in their own facilities. Provisioning is major issue not just in devices, but also in cloud software - its one thing to sign up for a service, its another thing to to get to 'doing useful things'. Most enterprise apps struggle with this.
Most hardware companies suck at making software. If AWS can get a decent traction, maybe they will replace their custom crap with better engineering software, which would be a win.
Also a win for AWS, of course, as this would make it easier to use their services.
[+] [-] mflamespin|6 years ago|reply
Realistically, Whirlpool just isn't going to be able to field that team to make their laundry machine resilient to malware attacks or a bricking update.
I always thought the only way forward with IoT was if it a big tech player offered an SDK / IoT platform that allowed developers to focus on the widgety part of their widget without having to think about the complexities of running an internet connected device. This seems like a big jump towards that.
(I worked at a wifi router company.)
[+] [-] zxcmx|6 years ago|reply
"Pray we do not alter the Terms and Conditions further". Walled gardens, app stores and closed ecosystems are FAANG staples at this point.
I think in many cases the technical delivery risks (say, having crappy updates, janky apps and the odd CVE) seem more survivable than taking on those kinds of business risks.
[+] [-] 2J0|6 years ago|reply
Everything I have since read about the major mobile hardware/phone companies taught me to stop over estimating the ability for organisations who are monomaniacally focussed on exploiting initial (fluke by statistical measures) in SF insights implemented by early engineering focus by arguably genius minds, have no ability whatsoever to understand how anything can interoperate or even coexist, because they are hell bent on protecting the boundaries of their product features and technology surface.
[+] [-] Ductapemaster|6 years ago|reply
Our offering comes down to three things:
1. Pre-certified hardware modules (open source [2]) that support WiFi or Cellular in a few form factors.
2. An on-device OS (also open source) that handles communication in the background and abstracts away the hardware using an Arduino-like API.
3. A cloud-based "command center" (closed source) that allows you to link up your backend services with events flowing to and from your devices via webhooks, manage over the air updates, and see connectivity metrics across your fleet. No data is stored - just ferried between your devices and the other end of the pipe that you configure.
Oh, and you can buy our devices off-the-shelf in small volumes and get them up and running in a few minutes!
[1] https://www.particle.io
[2] https://github.com/particle-iot
[+] [-] wiremine|6 years ago|reply
I think you're just using Whirlpool as an example, but they're not a great one. They have a fairly large IoT group that spans their entire ecosystem. (I'm a vendor in said ecosystem, and work with them on a weekly basis).
Your point is well taken, though: I work with many smaller companies on their IoT products, and they aren't in a position to manage their IoT projects.
[+] [-] loudmax|6 years ago|reply
Yes, well hopefully not _a_ provider who will lock their customers into a proprietary platform. Hopefully many providers so manufacturers have options to choose from. Even better would be if there is an open standard, and then providers can compete on providing a better implementation.
[+] [-] bsder|6 years ago|reply
If I'm the guy at the end and I'm good enough to build the device, I don't need the rent-seeking guy in the middle.
If I need the guy in the middle, I, by definition, am not good enough to be the guy at the end building the device.
[+] [-] CapriciousCptl|6 years ago|reply
[+] [-] saas_sam|6 years ago|reply
[+] [-] 2zcon|6 years ago|reply
You would be amazed how many of the big players are doing exactly that. But I shouldn't talk about it any more, I work for one.
[+] [-] inopinatus|6 years ago|reply
It merely remains for IoT device management to achieve the same level of maturity as plumbing. Wait a couple of millennia, we'll get it right.
[+] [-] andybak|6 years ago|reply
I bet you've got some stories to tell.
[+] [-] bzzzt|6 years ago|reply
[+] [-] dsalzman|6 years ago|reply
+1 to AMZ for their investment in FreeRTOS.
https://developer.amazon.com/frustration-free-setup [1]
[+] [-] CiPHPerCoder|6 years ago|reply
https://www.urbandictionary.com/define.php?term=FFS
[+] [-] edderly|6 years ago|reply
"We can solve any problem by introducing an extra level of indirection."
I'm extremely skeptical that this solves any particular problem other than for Amazon building devices, silicon vendors who want to be in Amazon devices. Which is fine, but the scope of this seems to be broader. It just doesn't sound like the right idea to me.
The biggest issue is the "common" part. You want to produce an api or abi common across OSs? How many chances do you have to get it right and not run into a web of api version bugs & issues? Who has made this successful in the past? UDI? (nope) And then you want a common api across an RTOS and Linux? Good luck.
Oh and by the way, where's the source code for this middleware?
I don't know why you wouldn't take the approach of making the underlying OS's easier to work with. If FreeRTOS is missing something, enhance it. If embedded Linux(s) are hard to integrate with, start an open source project to work on that problem.
[+] [-] juliansimioni|6 years ago|reply
[+] [-] black_puppydog|6 years ago|reply
[+] [-] lexicality|6 years ago|reply
[+] [-] loa_in_|6 years ago|reply
[+] [-] privateSFacct|6 years ago|reply
"Can" amazon, if they wanted, abuse this? It seems likely all the technical items are in place that they could. I don't see why they would, you are voluntarily putting everything they want into the device for them.
[+] [-] speedgoose|6 years ago|reply
It would be nice if they could do stuff such as updating the Linux distribution.
[+] [-] AceJohnny2|6 years ago|reply
https://www.mbed.com/en/platform/
[+] [-] jschwartzi|6 years ago|reply
[+] [-] ARothfusz|6 years ago|reply
[+] [-] simlevesque|6 years ago|reply
To update ubuntu with greengrass we made a lambda.
[+] [-] wiremine|6 years ago|reply
That said, this is solving a lot of real-world problems, and I'm glad to see them moving this forward.
[+] [-] m463|6 years ago|reply
[+] [-] drenginian|6 years ago|reply
[+] [-] DannyB2|6 years ago|reply
[+] [-] whoisjuan|6 years ago|reply
Basically it allows vendors to plug this low-level wrapper on top of their hardware's OS so they can easily add things like Alexa capabilities without writing their own API for that.
From what I understand, this is more or less what it does. It's like OpenWRT but for IoT devices and with the single purpose of integrating Amazon's SDKs in your hardware.
[+] [-] Ididntdothis|6 years ago|reply
[+] [-] crocodiletears|6 years ago|reply
[+] [-] downrightmike|6 years ago|reply
[+] [-] unlinked_dll|6 years ago|reply
[+] [-] andrewxdiamond|6 years ago|reply
https://azure.microsoft.com/en-us/services/azure-sphere/
[+] [-] pjmlp|6 years ago|reply
[+] [-] soonnow|6 years ago|reply
[+] [-] zoom6628|6 years ago|reply
[+] [-] dpeck|6 years ago|reply
They may have more success than Apple has had, but I'm not so sure the incentives are in place to make general IoT devices less terrible.
[+] [-] kempbellt|6 years ago|reply
I got it working for my Phillips Hue devices maybe twice before I ended up going the DIY route.
[+] [-] outworlder|6 years ago|reply
Also a win for AWS, of course, as this would make it easier to use their services.
[+] [-] ageofwant|6 years ago|reply
[+] [-] solarkraft|6 years ago|reply
[+] [-] mnemonicsloth|6 years ago|reply
[+] [-] odiroot|6 years ago|reply
[+] [-] paxys|6 years ago|reply