Posts Tagged ‘Internet Of Things’
Big Consulting Cos and IoT Platforms
Platforms dominate the conversation when it comes to the IoT. Consulting companies, who thrive on providing their expertise and analysis on all things technology, have weighed in on the advantages & disadvantages of IoT platforms.
These companies have limited information available publicly. Here is an overview of what the three of the big consulting companies think about them:
Boston Consulting Group (BCG)
In a blog post titled “Who Will Win the IoT Platform Wars?”, BCG outlines key factors in selecting the IoT Platform:
Select a fully capable platform – According to BCG’s definition of an IoT platform, most IoT platforms are not really platforms – they are partial offerings. And hence the need for selecting a platform carefully.
Evaluate your risk appetite – given that majority of the platforms are provided by startups – BCG warns about stability and security of the platform provider.
Match the platform to your developers’ skills – BCG recommends that careful attention should be paid to the programming environment of an IoT platform and how it matches or not the software skills of your own development team.
Consider openness and ease of integration – whether the platforms supports modular and easy to use APIs, and easy-to-integrate framework to fit with existing IT architecture
Select the platform business model that fits your needs – BCG gets into the ability of platforms to provide more than horizontal services and addressing specific vertical use cases.
The blog post (even though it is dated June 2017, months after several important Edge related announcements) has a glaring omission around Edge Processing and Compute or Fog Computing.
McKinsey
McKinsey in a blog post titled “Making sense of Internet of Things platforms” outlines 10 questions to ask before choosing an IoT Platform. 3 of these questions are centered around Applications, 1 of them is on Infrastructure and 2 of them around Edge process/control.
Application environment – stresses on the importance of applications provided with the platform – in some respect this identifies with vertical use-case factor outlined by BCG – because applications are typically use-case specific. This factor includes integration capabilities with the Enterprise IT.
Data ingestion and wrangling – this factor stresses on ensuring that the data management and processing capabilities match the needs of the companies use cases.
Ownership of cloud infrastructure – in summary this factor delves into ensuring that the the company’s cloud strategy is aligned with that of the IoT platform.
Data sovereignty and security – this factor is somewhat related to the cloud infrastructure but is listed separately – this delves into where the IoT data is stored, and how does that relate to the data protection, privacy and security requirements of your company.
Edge processing and control – the importance of distributing the application code and data between the edge (closer to the devices and things) and the cloud.
Accenture
Accenture’s approach is different from McKinsey and BCG – they have built their own IoT platform. “IoT Platforms – The engines for agile innovation at scale” document published by Accenture outlines the following three important factors of an IoT platform:
Component library – a curated library of interoperable components that allows for rapid prototyping
Component capture – a semantics-based method for capturing new components or adapting existing ones so they are interoperable
Component configuration – a mechanism that simplifies the user’s ability to compose, configure and deploy components to create a new application.
Accenture has built several apps that are vertical specific on top of their platform. The PDF gets into how they built these apps on the platform.
Bottomline – each approach has a certain degree of overlap, however it is clear that all three of them have ensured that there strategy and recommendations on IoT platforms are unique & differentiated from other consulting companies.
Connectivity and Protocols in IoT: Thoughts on picking the right one
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.
IoT Platforms: Dominance of AWS
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 – 104.130.163.78).
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.
Implications:
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.
8 Attributes of a Full Stack IoT Company
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
The Rise And Fall Of The Full Stack Developer
A16Z’s Ben Horowitz did an interview (in Jan 2014) talking about Full Stack Startup
Internet of Things: IP or Not
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.
4 Implications of Apple’s HomeKit
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?
IoT Stories (Week Ending May 31st 2014)
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.
Alain Louchez over at InformationWeek takes another Pew Research report and explains how the manufacturing in the US can benefit with the aging workforce and 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.
Exploring the Internet of (Every)Thing
Last year I embarked on a journey to explore the Internet of Things or as Cisco calls it “Internet of Everything” (IoE). I like the notion of IoE not because it is coined by my day job employer but because it is about everything. Smartthings, the much talked about IoT startup, talks up the “Physical Graph” because thanks to the Social Networking era the term “Graph” puts you in vogue. [But really graph? do we want to be relegated to a 2D world of graph?]
I have installed, experimented, hacked and studied many IoT offerings, here is the current list:
Philips Hue (and my review here & here)
Wireless Sensor Tags (my review here)
Nest (Teardown/Review of here and here)
All the above and more are enabling discrete systems to get connected – the first step towards the IoE. As these systems proliferate and standardize in terms of presence and interoperability the need for a fabric that ties all of them together will emerge. I believe Tim O’Reilly describes this notion very well – Software above a Single Device.
I am excited to play a role in tying together the Internet of Everything.
Nest 2 Teardown
I had an opportunity to teardown the Nest 2 Thermostat – it is even more beautiful inside then the outside. It packs an amazing amount of technology, here is a list of major components I found as a part of the teardown:
1. System On a Chip (SOC): The Nest 2 is powered by the Texas Instruments AM3703CUS SOC. It belongs to the Sitara family of MPUs. You can read about it here.
2. One major change I discovered was that the Nest 2 has moved away from the Texas Instruments Zigbee chip the 2530 and is using the Ember (Silicon Labs now) EM357 for its yet to be shown of Zigbee functionality. You can find about the EM357 here.
3. There is a chip from Skyworks – the Sky65384 that I could not locate on their website.
4. The WiFi implementation is a module from Murata – the logo is definitely Murata – and when you do a Google Search for “murata sl s235” – the first hit is the SL modules on the Murata page, and it mentions that the SL modules are based on the TI WL1270 Chip. It would be interesting to know if it uses the newer version of the 1270 – the 1271 – which would have a Bluetooth radio integrated as well.
5. Memory appears to be Mobile DRAM from Samsung, here and here are the links with the information on the memory.
All Things CC: 