Posts Tagged ‘Internet Of Things’
There’s lots of ways to move from Point A to Point B: trains, ships, and planes. We instinctively assess the logistics of travel by basing our decisions on factors like distance, cost, and urgency.
If we have to ship goods, similar logic comes into play. It is cheaper to plan in advance if you are importing goods from China to the US. If the delivery of a good is important enough, you would have your product air-shipped.
Barring specific nuances, the same approach needs to be taken for picking up IoT protocols and connectivity options.
- Range between the communicating nodes – for example between the sensor and the gateway.
- Reliability of signal between the communicating nodes – range alone is not enough.
- Latency (time it takes from one to another)
- Throughput/Bandwidth – how much usable information (not the raw rate) can you send through at a time
- Power Source: is it battery powered or not?
- Security: while security is extremely critical – it needs to work at a system level based on the rest of the parameters
- Ease of use, installation and maintenance: these translate to cost, and impact profitability
Note – ‘Node’ above implies all types of physical entities involved in interacting and communicating with each other – devices, sensors, gateways, cloud etc.
Things to keep in mind:
Don’t be myopic when making decisions! For example when addressing the cost of the solution – evaluate more than the COGS (cost of goods). Address, for example, costs associated with installation, provisioning and subscription for data network. To quote a British saying – “don’t be penny wise, pound foolish”.
Do make your decision with eyes wide open – tactical business pressures may prevent you from making a strategic decision – do make a note of the reasons and document them. For example if you are reducing requirements to meet a deadline – make a note of it. Be clear on the reasons you are making so as to adapt the architectural evolution of your IoT application.
Don’t get stuck in an analysis / paralysis. This is a counter-point to the first one. Don’t be stuck in an endless cycle of analysis. Take a decision. Ensure that your system design and development approach is in sync with decision. Make sure trials are rapid, especially in real world environments.
Needless to say there is no dearth of IoT Platforms offering you the opportunity to get your “things” and “devices” connected, and reap the benefits of IoT.
It is interesting to note that Amazon continues to dominate in this segment of Cloud Computing as well. I ran a rudimentary script to lookup up where the developer sites are hosted for different IoT platforms, the results were pretty interesting – 8 out of 10 are being hosted on AWS (Disclaimer – it is not clear to me if their entire platform is on AWS or only the developer front end). This is actually 8 out of 9 since I wrote the script originally because Thingworx and Axeda platforms have merged (all three URLs, the two old ones, and the new ThingWorx.com resolve to the same IP – 220.127.116.11).
And the surprise was Nest – an Alphabet/Google Company is still (after more than two years of being acquired) – has its Developer site running on AWS!
Take a look at the screenshot of the output below, and if you want to run the script yourself, and try other sites – copy the script at Gist.
It also brings up an interesting challenge for these companies now that Amazon has AWS IoT – Cloud Services for Connected Devices. AWS IoT may not offer the level of completeness that others may offer such as Ayla or Exosite but the AWS IoT feature set is comprehensive enough to reduce the differentiation between them. The other choice is to go with Google, Microsoft and IBM – and all three of them also have IoT enhancements and features to their cloud offerings.
The choice of not going with Cloud PaaS is equally devastating because it is going to be costly for IoT platforms or they will lack the scalability.
I feel this will accelerate consolidation in the IoT platform space (like Microsoft’s acquisition of Solair) or companies being unable to offer the scale that is needed for IoT.
Chances are, if you are in the business of technology, you have come across the term “Full Stack”. It started few years back with the notion of a (software) developer being able to program all layers for web applications – you can find a great description from 2012 here: What is a Full Stack developer?. The momentum, and market for Full stack developers kept going up. And then it started being discussed at the level of a company or rather a startup – and I would attribute it to the VC firm A16Z to define it at this level. A16Z has dedicated a page on the Full Stack Startup as a part of their ‘trends‘ in investing. The ideal full stack company is Apple – they do everything top to bottom, providing the best user/consumer experience to their customers (readers may be familiar with the previous iteration of full stack – the Vertically Integrated Company – I’m not sure how it is different from the definition of Full Stack).
This got me thinking on what are the attributes, skills, expertise needed by a Full Stack IoT Company – a company that build a complete solution based on the benefits of IoT, and here they are:
1. Hardware design, development and manufacturing: This may or may not be part of a full stack IoT company but the reality is that the T in IoT stands for “Things” – physical things. And interfacing with them requires hardware. Full Stack IoT companies will own or control significant aspects of the hardware required in their solution. This implies the Full Stack IoT company needs skill around design, development of hardware. And as many delayed Kickstarter hardware projects prove – these companies would need expertise and experience in manufacturing, and supply chain. The hardware would involve both the sensor and the gateway being used.
2. Embedded / Firmware (resource-constrained) Programming: IoT has re-surfaced the lost art of an embedded programmer. Imagine the code running inside the wearables or sensors – it is all embedded code and in some cases running without any real operating system. Design, development and debugging is fundamentally different than cloud or mobility or application level programming.
3. Application-level & Middleware Programming: Programming on the IoT Gateway, Cloud and the distributed middleware to integrate all of the elements together
4. Cloud development, and operations: All IoT applications require a cloud component, you would need the cloud infrastructure (e.g. Amazon AWS), the IoT middleware portion running on the cloud and the IoT application which provides the functionality.
5. Management – of devices, of applications, of network (even though the network belongs to a third party): as the solution provider – managing devices, and apps – for version control, updates would be needed as a part of the integrated offer and solution. Once again – the Full Stack IoT company may license or integrate a third party solution but would own the responsibility.
6. Smartphone & Tablet Apps: Do I really need to justify this? You would need apps to both for management of the IoT application and also for consuming the experience provided by the application.
7. Analytics, Mining, Business Intelligence: ideally the company provides basic analytics with its solutions, and can be integrated with other products and solutions for advanced analytics. Full Stack IoT companies may leverage analytics solutions from other companies, but would still retain control of the data.
8. Integration with IT & other systems – to interface, and integrate with business applications in order to deliver the contextual value provided by the IoT system. Your IoT application may also need to integrate with other services to enhance your service – for example you may need to integrate with a Weather reporting web service if you are offering an application that controls/manages air conditioning (HVACs).
Bottom line – IoT applications are distributed across multiple systems and that is both a challenge and an opportunity! Whether your company is a “Full Stack” IoT company or not – if you building IoT applications – you cannot escape the 8 attributes described above. You will have to partner, build or integrate that help address all the 8 elements.
Full Stack Reading
Rethinking the Internet of Things: A Scalable Approach to Connecting Everything (which BTW is free for the Kindle Edition) makes the case for a Non-IP (non Internet Protocol) stack approach for “things” to be connected. While I am in agreement in the author, the approach seems to be all or nothing – which is not true either. I feel that for constrained devices, that emit limited data and require low bandwidth – a non-IP approach makes sense. I am not entirely clear on how many of those billions of connected devices are really simple/constrained devices.
There would be three categories of “things” based on how they connect to the Internet:
1. Devices/Things that have the resources (CPU/Memory/Connectivity) to support and run the TCP/IP stack similar or identical to ones found in PCs/Macs/Tablets/Smartphones.
2. Simple, Standalone Devices or Things: More like sensors that have limited resources making it unsuitable even for running the constrained version of IP stack – 6LoWPAN and its variants – will need to support a connectivity protocol/stack that is ideal for the low bandwidth, long battery life requirements.
BTW these type of devices/things have been around for decades now – however getting them connected to the “Internet” allows making their data available, and hence unlocking the value.
3. Complex Devices/Things – These are hybrid of 1 and 2 that is they have their own “network” not based on IP – and may leverage connectivity/protocol specific to its industry or use case. And it has a integrated gateway or bridge that takes relevant data back and forth between IP and its internal Non-IP network. A great example of this is an Automobile (now popularly in the IoT vernacular being called “Connected Car”) – the automobile makes use of CAN Bus (since the 1980s). Autos are now connecting up to the Internet using Wi-Fi or 3G/LTE (or both), and they are building in functionality to go back and forth over an IP connection to the CAN Bus as well.
HomeKit defines a language, API, taxonomy (albeit for IOS devices only) to discover, pair, and control home automation devices (more about it here). The technology is very interesting, but it has implications and raises questions:
1. AllSeen/AllJoyn defines a protocol for a proximal network (i.e. local to the premise) and is limited to Wi-Fi with some support for Bluetooth. HomeKit is solving a very similar if not identical challenge. What would manufacturers prefer – AllJoyn/AllSeen or HomeKit? With limited resources would they give priority to AllSeen/AllJoyn?
2. The basis of HomeKit, appears to be a common database where information on the Accessories is stored – there location within home, the common name given to them, rooms they are in etc. Would for example the IOS App for Comcast Xfinity Home or AT&T Digital Life be willing to give access to their devices to other app developers? I am willing to bet because their solutions are anchored on professionally managed security, they probably will not.
3. AT&T and Comcast (as an example because their home automation & security service is widely deployed in the US) may not open up access to devices their systems control in their IOS apps however consumer apps for Philips Hue or NetAtmo using HomeKit would probably allow access. Do you think the likes of Philips Hue or NetAtmo would be ok with that? Or would be their policy controls in place during app approval or access controls allowing some degree of control to Philips and NetAtmo as an example?
4. HomeKit will have complex scripting capabilities – going beyond what IFTTT can do. HomeKit possibly solves the software challenge much better than Revolv with its consolidated app for controlling many things through its hardware (in reality controlling the Wi-Fi or Ethernet connected devices such as Philips Hue or Sonos does not require their hardware/gateway). What role do companies like IFTTT (from a HomeAutomation perspective only, not the many other functions it provides. IFTTT has simple if-then rules only today operating through the latency of an internet connection) or Revolv play with HomeKit? Did Apple disintermediate the likes of IFTTT for Home Automation and Revolv?
Pew Research Center recently released a report titled The Internet of Things Will Thrive By 2025. This was, obviously, picked up by many news and blog sites. Washington Post’s Mohana Ravindranath wrote about it in a post titled “Some see possible drawbacks in ‘Internet of Things’”, and provides a good summary. The post has one typo – it claims 1,900 people responded, whereas actually of the 12,000 people canvassed 1,606 responded. He has summarized inputs fromVint Cerf, Andrew Bridges, John Senall and Miguel Alcaine. Mohana has captured good set of quotes from one of the authors of the report – Lee Rainie, director of Pew’s Internet & American Life Project. Wired has good summary of the report as well.
Scot Stelter over at RFID Journal mentions the report but points out the lack of coverage in that report with respect to RFID, his post (RFID Stakeholders Need to Prepare for the Internet of Things) has good insight into how RFID will be important, and professionals in the RFID field need to be prepared for IoT.
Last week was the week before Apple’s WWDC – and lot of speculation on how Apple is going to play in Home Automation and IoT started out by Financial Times in Apple seeks to work Jobs magic on the internet of things (paywall). GIgaOm’s Stacey Higginbotham explains it well in Here’s how Apple’s smart home program will work. EETimes in “Apple’s IoT ‘Good Housekeeping’ Label: MFi “ gets into a little bit more detail and indicate that it involves around the MFi program (just as Stacey’s post) but indicate that it would support ZigBee protocol as well. Roger Kay at Forbes jumped in with “Will Apple Play Nice On The Internet Of Things?“. Roger makes the case that Apple won’t be in a position to dominate unlike the Smartphone or Tablet segment. While I agree with that analysis, Apple may continue to influence and benefit because Smartphones & Tablets will be an integral part of most IoT solutions.
The Economist gets into the over-hype around IoT – a very nice and thought provoking article titled The internet of nothings. It covers the chart put together by ZDNet on showing the surge in Google search aassociated with IoT, how the acquisition of Nest marks a tipping point. Two interesting observations:
#1. The post points out the real challenge is connecting the Cloud and the Node (Sensor or Actuator):
Devising sensors and algorithms to handle the front- and back-ends of the IoT are the easy part. Unfortunately, few developers are tackling the really difficult bit in the middle—the myriad infrastructural gaps that lie between the sensors in things at the edge of the internet, and the data collection and analysis performed by servers in the cloud at the centre.
#2. It questions the numbers being published (on number of connected devices) especially claims being made by Cisco:
…while Cisco Systems, a network-equipment firm in California, expects there to be no fewer than 50 billion. Cisco is so enamoured of the IoT that it has installed a “connections counter” on its website. On May 26th, the number of “things” connected to the internet was over 12.4 billion and counting.
The vast majority of the billions of things connected to the internet on Cisco’s website, for instance, are not the toasters, refrigerators, thermostats, smoke detectors, pace-makers and insulin pumps that the IoT’s true believers enthuse about. Almost exclusively, they are existing smartphones, tablets, computers and routers, plus a surprising number of industrial components used to beam performance statistics back to corporate headquarters.
Talking about Google, Business Insider is covering its rumor to buy DropCam (originally reported by The Information). It is probably pure speculation but if it bears fruit – Google could be really powerful in combining Dropcam, Nest, and Android (and YouTube/GoogleTV/Chromecast in the living room) and bringing order to Home Automation & Monitoring. Dropcam cameras have motion detection, Nest has a proximity sensor and between the two they could make for a solid, self-managed security system as well.
This week’s links also has a story with a cliche headline “With ‘Internet of Things,’ your fridge will know when milk is low“. This resulted in an interesting exchange on Twitter which you can read here. The blog post title is misleading because the focus is more on security. It has been distributed over many different websites – for example you can find it here and here.
Intel, Qualcomm and Freescale are three semiconductor companies that tend to show up in IoT Articles. This week I came across a post by Lee Schafer that starts off going over the Texas Instruments Launchpad:
On the Texas Instruments eStore it takes only $19.99 to jump into “the Internet of things” by purchasing a Connected LaunchPad unit to bring an everyday device onto the Internet. Better be patient, however, because they are sold out.
Finally a post on Wired is definitely worth reading – ‘Beautiful mistakes’ will form groundwork for the internet of things. The essence of the post:
Similarly, it will take user-generated products and hacked physical connections for brands to make sense of the internet of things. It will be ugly, soldered-together networked devices (not the gamified toothbrush) that will light the way for them. Beautiful mistakes and unexpected outcomes that will form their strategies.