Among the words, phrases and acronyms in the Tech worlds “Platform” seems to be a word which seems to grab the headlines. If one listens to any pitch from a start up venture it would be not uncommon to get the “platform pitch”in at least 1 out of 2 proposals. A lazy search on Google on the “Top 20 Tech weary words” fetched me the result that “platform was 3rd in the list . (https://www.businessinsider.com.au/the-worlds-top-20-tech-weary-words-for-2014-2014-5).
There have been words verbalised like “Being Platformed” as well and a host of books on the significance of platform in the Technology world. I will not go into the virtues of platform. I would dwell on how the leaders in respective segments are a few ( a maximum of 3 ) while in the IoT world we seem to have by some counts 170 of them ( McKinsey ) to 400 of them ( Beecham Research).This is definitely a bewildering array to go through and investigate .
What is a Platform – why there are only a few platform leaders ?
Stepping back – different people have different views and meanings of the word “platform”. To get a view of the diversity of platforms we have:
Browsers (Chrome and Firefox) ,smart phone operating systems ( iOS and Android) , blogging (Word Press , Medium ) .Social Media titans (YouTube, Facebook) and even Instagram are described as platforms. Uber, Airbnb and their ilk are widely described as ‘marketplaces’, ‘platforms’ or ‘marketplace-platforms.’ Web services (Google Payments, Amazon Elastic Cloud) and gaming consoles (Xbox, Apple’s ipod Touch, Sony Playstation). One interesting point to be noted that in each category the market is mostly duopolistic .
To accommodate this diversity the safest definition of platform would be as :
- An extensible codebase of a software-based system that provides core functionality provided by the modules that interoperate with it, and the interfaces ( aka Application Programming Interface (APIs)) through which they interoperate. In effect this system abstracts a number of common functions without bringing out the complexity of building and managing them , for the users .
- The goal is to enable interactions between producers and the consumers
- This is enabled through three layers comprising the Network ( to connect participants to the platform), Technology Infrastructure ( to help create and exchange value ) and Workflow and Data ( thereby matching participants with content , goods and services ) .
This definition brings in the 2 dimensions of a platform. One that would be for internal use and the other for external use .
- An internal dimension for building platforms is to ensure all necessary modules interoperate , and
- An external dimension for building platforms is to enable interaction with the outside world and make it as accessible and usable as is possible.
Internal dimension led platforms focus on internal productivity and efficiencies and focus on users. Here the development is internally sourced and is essentially built for internal use . The external dimension led platforms focus on the supply (developer side) and the demand (user side) . Essentially they are sometimes termed as “two-sided” platforms .The development beyond a point is crowd-sourced and they enrich the platform and the platform reaches out to them through APIs.
In most of the cases if the external dimension is well evolved then the internalities come with the efficiencies by default; with respect to design quality , selection of interfaces leading to interoperability , robustness of infrastructure , seamlessness in workflow and data streaming .
External dimension platforms compete for both users and developers
Here one important aspect to be remembered is a Platform may not be ready to provide solutions to contextual and domain specific problem statements. Applications built around the platform do that, these applications help get the Return on Investment ( RoI ) from the platforms .
In any segment you must have seen that the winners are a few ( atmost 2 or 3 , aspirants may be many, who progressively wither away ) .The reasons has been presented above with respect to design quality , interoperability, infrastructure robustness and seamlessness in workflow and data flow and the last but not the least excellent and friendly user interface . Not many can master all the 4 aspects .These help acquire a critical mass of customer base which keeps growing and a duopoly of sorts is created in the market space .
Successful platforms have the ability to support the variety of business use cases in the present and have strive to build the design to evolve over time and be to an extent future ready .
The Bazaar of IoT platforms- The reasons & who would be the winners wading through the maze ?
Now when coming to Internet of Things (IoT) , The IoT movement repeatedly talks about platforms, but those definitions don’t align with any of Uber, Medium or Android. The first issue is interoperability. And none of these align with each other either.
Now let us address the question is the why of “plethora of platforms” in IoT .
It can be seen clearly that a typical architecture of an IoT solution is multilayered. The layers to simplistically put would be Device to Device ( this involves hardware and firmware with Low Range Communication ) , Device to Server ( which would again involve hardware and communication ) and server to server ( which would mean that cloud based application and long range communication would hold the key along with network , data storage and data visualisation ) .
So we see protocols and standards are driven through their origins from communication technologies ( we see Telecom companies like AT&T and Verizon leading here ) , in the data storage area ( we have Amazon , Google leading the way ) , in the application side ( Azure from Microsoft and Thingworx from PTC being the prominent ones ) . Companies which has a library of business use cases with them given the dominance they have in their respective businesses (namely Bosch , GE , Honeywell ) have the ambition to build their community based platforms .Then we have a host of start ups who run a platform per a business use case they address .
So the genesis of the “plethora of platforms” in the multilayered solution stack of IoT . This adds to complexity and hence no one player can be a leader across the layers as on date .
In the coming years it could be reckoned that there would be a shakeout in the market and the platforms could veer around key broad based use cases of remote monitoring and environment conditioning , predictive maintenance and process automation .
The ones which will win the battle of supremacy would have cracked the codes of
- Open interfaces,
- Carrier grade reliability,
- Service levels,
- Scalability and
- And allow for aa seamless integration into the back-office environment which is essential to the enterprise’s business operations.
- With a impressive usability and user interface .
Given the multitier architecture and the attendant complexity it will be a while before a small group of winners starts to bubble to the top . Some of the also-ran aspirants may focus on domains and address a specific part of the ecosystem in which to play or in the industry segments like home or industrial to justify their presence .
When you think about consumer cloud platforms, which ones come to mind? Amazon AWS, Microsoft Azure and Google’s Cloud Platform are likely to be at the top of your list. But what about industrial cloud platforms? Which ones rise to the top for you? Well, GE’s Predix, Siemen's MindSphere, and the recently announced Honeywell Sentience are likely to be on any short list of industrial cloud platforms. But they aren’t the only ones in this space. Cisco's Jasper, IBM’s Watson IoT, Meshify, Uptake, and at least 20 others are competing to manage all those billions of sensors that are expected to encompass the Industrial Internet of Things (IIoT). Which one do you think will end up dominating the market?
A Brief Overview of Cloud Computing
To answer the above question, let's start with a very brief overview of cloud computing to put industrial cloud platforms in their proper context. Cloud platforms are one of several services that cloud computing providers offer, with the main ones being: Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS).
Three Main Services of Cloud Computing
Software as a Service (SaaS)
Platform as a Service (PaaS)
Infrastructure as a Service (IaaS)
Industrial Cloud Platforms by Industrial Companies
Industrial cloud platforms have a much deeper focus on operational technology than consumer platforms. They are designed to allow data gathering throughout manufacturing production processes, in order to improve performance as well as predict failures before they happen. Here are three industrial cloud platforms by long time industrial companies:
Industrial Cloud Platforms by Software Development Firms
Industrial companies aren’t the only ones developing industrial cloud platforms. There’s already a long list of industrial cloud platforms available from software development firms. Here are a few worth mentioning:
|Table 1: The List of Industrial Cloud Platform Providers|
IBM Watson IoT
SAP Hana Cloud
What Do You Think Will Be The Future of the Industrial Cloud?
Will there be a dominant Industrial Cloud Platform? It's hard to say at this point. GE Predix is hoping for 500,000 connected devices by the beginning of 2017, while C3 IoT is said to have 70 million devices connected to its platform already.
The Crowded Cloud of Industrial Platforms
Will this market consolidate around a few big-name platforms, or will a lesser known provider be the winner and take all?
This post originally appeared here.
Let’s say you’re in the planning phase of an IoT project. You have a lot of decisions to make, and maybe you're not sure where to start:
In this article, we focus on a framework of how you can think about this problem of standards, protocols, and radios.
The framework of course depends on if your deployment is going to be internal, such as in a factory, or external, such as a consumer product. In this conversation we’ll focus on products that are launching externally to a wider audience of customers, and for that we have a lot to consider.
Let’s look at the state of the IoT right now— bottom line, there’s not a standard that’s so prolific or significant that you’re making a mistake by not using it. What we want to do, then, is pick the thing that solves the problem that we have as closely as possible and has acceptable costs to implement and scale, and not worry too much about fortune telling the future popularity of that standard.
So, it first comes down to technical constraints:
- What are the range and bandwidth requirements?
- How many nodes are going to be supported in the network?
- What is the cost for the radio?
That radio choice has big impacts—not only is it a hefty line item on your BOM on its own, it’s also going to determine the resources that the device needs as well. For example, if you have a WiFi radio at the end, there’s considerable CPU and memory expectations, whereas if we have BLE or some mesh network, it’ll need a lot less. There’s infrastructure scaling costs to consider as well. If we go WiFi: is there WiFi infrastructure already in place where this is being deployed? How reliable is it? If we’re starting from scratch, what’s the plan for covering a large area? That can become very costly, especially if you’re using industrial grade access points, so it’s important to consider these effects that are downstream of your decision.
Zooming in on specific standards
In our opinion, the biggest misconception we find: “Isn’t there going to be one standard to rule them all?” There’s no future of that, and it’s not just because we’re never going to all agree on stuff as an industry, it’s because in many cases different standards aren’t solving the same problems differently, they are solving different problems. So understanding that, we can now look at what each protocol attempts to solve and where they live on the OSI model, or "the stack."
Some would suggest that it is a full protocol to do communication from a device to a server, but it’s not quite that. MQTT is used as a data format to communicate to something, and that payload can be sent over any transport, be it WiFi, mesh, or some socket protocol. What it tries to solve is to define a way to manipulate attributes of some thing. It centers around reading and writing properties, which lends itself very well to an IoT problem. It certainly saves development time in some regards, but depending on how strictly you’re trying to implement it, it may cost you more development time. As soon as you one-off any part of it, you have to document it really well, and at some point you approach a time and cost factor where implementing your own payload scheme may be a better option.
Is it prolific enough to where you should absolutely use it? No, it hasn't reached that level, and it won’t likely reach that level. What it is right now is a convenient standard for device-direct-to-cloud where we don’t control both ends because it gives some measure of a common language that we can agree on; however, the thing to keep in mind is that most of the time it does in fact need additional documentation—what properties are being read/written and what the exact implementation looks like—ultimately, you’re not getting out of a lot of work using MQTT.
Also starting at the network layer, Zigbee and Z-wave are the big incumbents everyone likes for mesh networking. They attempt to solve two problems: provide a reasonable specification to move packets from one place to another on a mesh network, and actually suggest how those packets should be structured; so, they both reach up higher in the stack. And that's the part hinders their futures. For example, Zigbee uses a system called profiles, which are collections of capabilities, such as the smart energy profile or the home automation profile. When a protocol gets so specific as to say ‘this is what a light bulb does’ it’s pretty difficult to implement devices that aren’t included in the profile. While there are provisions for custom data, you’re not really using a cross-compatible spec at that point—you’re basically off the standard as soon as you’re working with a device not defined in the profile.
The other consideration with these two is that they are both routed mesh networks. We use one node to communicate with another node using intervening nodes. In other words, we can send a message from A to B to C to D, but in practice we’ve sent a message from A to D. As routed meshes, each node understands the path the message needs to take, and that has an in-memory cost associated with it. While Z-wave and Zigbee have a theoretical limit of 65,535 nodes on a network (the address space is a 16-bit integer), the practical limit is closer to few hundred nodes, because these devices are usually low power, low memory devices. The routing also has a time cost, so a large mesh network may manifest unacceptable latency for your use case. Another consideration, especially if you’re launching a cloud controlled consumer product, is that these mesh networks can’t directly connect to the internet—they require an intervening bridge (a.k.a gateway, hub, edge server) to communicate to the cloud.
A final caveat is that Z-wave is a single source supplier—the radios are made and sold by Zensys, so you have to buy it from them. Zigbee has a certification process, and there are multiple suppliers of the radio, from Atmel to TI.
You really just can’t compete with the amount of silicon being shipped based on Bluetooth. 10,000 unique SKUs were launched in Bluetooth in 2014. Other than WiFi, there’s nothing that compares in terms of adoption. Bluetooth was originally designed for ‘personal area networks,’ with the original standard supporting 7 concurrent devices. And now we have Bluetooth low energy (BLE) which has a theoretically infinite limit. BLE did a ton to optimize around IoT challenges. They looked heavily at the amount of energy required to support a communication. They considered every facet of "low energy," not just the radio-- they looked at data format, packet size, how long the radio needed to be on to transmit those packets, how much memory was required to support it, what the power cost was for that memory, and what the protocol expects of the CPU, all while keeping overall BOM costs in mind. For example, they figured out that the radio should only be on for 1.5ms at a time. That’s a sweet spot—if you transmit for longer, the components heat up and thus require more power. They also figured out that button cell batteries are better at delivering power in short bursts as opposed to continuously. Further, they optimized it to be really durable against WiFi interference because the protocols share the same radio space (2.4GHz).
And then CSR came along and implemented a mesh standard over Bluetooth. Take all the advantages afforded with BLE, and then get all the benefits of a mesh network. The Bluetooth Mesh is flood mesh, meaning instead of specific routing to nodes, a message is sent indiscriminately across all nodes. This scales better than routed mesh because there’s no memory constraints. It’s a good solution for many problems in the IoT and at scale is probably going to be the lowest cost to implement.
An up and coming standard that’s built on top of the same silicon that powers the Zigbee radio. It solves the problem of mesh nodes not being able to communicate directly to the cloud by adding IPv6 support, meaning that nodes on the network can make fully qualified internet requests. There’s a lot of weight behind this standard. Google seems to think it’s interesting enough to make their own protocol (known as “Weave”) on top of it. And then there’s Nest Weave which is some other version of Google Weave. As it stands, it takes a long time for a standard to really take hold-- you can immediately see how the story with Thread is a little muddier, which will not help its adoption. It’s also solving a problem that it just doesn’t seem that many devices have. Let’s take sensors as an example. Do these low power, lightweight, low cost, low memory, low processing, fairly dumb devices NEED to make internet requests directly? With Thread, each node now knows a lot more about the world—where your servers are for example, and maybe they shouldn’t be concerned with those things, because not only do the requirements of the device increase, but now the probability and frequency of having to update them in the field goes way up. When it comes to the actual sensors and other endpoints, philosophically you want minimize those responsibilities, except in special cases where offline durability, local processing and decision making is required (this is called fog computing).
When Thread announced their product certification last year, only 30 products submitted. Another thing to note about Thread's adoption is that the mesh-IPv6 problem has been solved before-- there’s actually a spec in Bluetooth 4.2 that adds IPv6 routing to Bluetooth, but very few people are using it. Although Nordic Semiconductor thought it was going to be a big deal and went ahead and implemented it first, it just hasn’t come up much in the industry—that happened Q4 2014 and no one’s talking about it.
One thing Thread does have going for it is that it steps out of defining how devices talk to each other, and how devices format their data—doing this makes it more future proof. This is where Weave comes in, because it does suppose how the data should be structured. So basically a way to look at it is that Weave + Thread = direct Zigbee/Z-wave competitor. We haven’t seen anyone outside of Google really take an initiative on Weave, other than Nest who have put a good marketing effort into making it look like they are getting traction with it.
Other protocols live higher in the stack and remain agnostic at the network layer. The most well known of these is probably Qualcomm’s Alljoyn effort. They have the Allseen Alliance, although their branding is a bit murky—Allplay, AllShare, etc. We’ve seen some traction with it, but not a ton-- the biggest concern that it’s fighting is that it’s a really open ended protocol, loosely defined enough that you’re really not going to build something totally interoperable with everything else. That’s a big risk for product teams. If there aren’t enough devices in the world that speak that language, then why do I need to speak it? That said, LIFX implemented it, and it worked really well for them, especially since Windows implemented it as well. Now it’s part of Windows 10—there’s a layer specifically for AllJoyn stuff and it seems to do well. There's evidence with AllJoyn that you can bring devices to the table that don’t know anything about each other and get some kind of durable interoperability. However, at a glance, it seems complicated—the way authorization is dealt with and the way devices need to negotiate with each other. There really isn't runaway adoption.
They’ve ruled the roost with their 802.11 series. B then G then A, and now we have AC. 802.11 has been really good at being simple to set up and being high bandwidth. It doesn’t care about power consumption, it’s more concerned with performance because it’s meant to be a replacement for wires. Almost 2 years ago, they announced 802.11 AH which they’ve branded as HaLow, which attempts to address power, range, and pairing concerns of classic WiFi. Most WiFi devices are not headless ("headless" - no display or other input), they have a rich user interface—meaning we can login and configure them to connect to WiFi. Pairing headless devices has been a very tedious process. With HaLow, they’re solving two problems—how do we get things on easier, and how do we decrease the expectations (particularly power) of the device running the radio. It’s too early to know what type of traction this will get, but IEEE has a great track record at standards adoption.
More like: LoRa vs. SIGFOX. With these protocols we’re looking at how to connect things over fairly long distances, such as in smart city applications. LoRaWAN is an open protocol that's following a bottoms-up adoption strategy. SIGFOX is building out the infrastructure from the top down, and handing APIs to their customers. In that way, SIGFOX is more like a service. It'll be interesting to see the dance-off between these two as the IoT is adopted in these more public-type applications.
That’s the body of standards that need to be addressed. There’s a ton more, but we don’t see them as exciting for the IoT today.
As the platform race continues to mature for the IoT, we found a great post by by Thierry Lillette that looks into the platforms, ecosystems and products. Good reading for any IoT and digital professional. Originally posted here.
These days it feels like any successful company, especially the so-called unicorns (aka private companies with over $1 billion valuation) are not selling a product but leverage a platform. Beyond the Silicon Valley lingo, there is also a growing body of work in the literature dealing with platform businesses and business ecosystems.
The end of the sustainable competitive advantage
New digital technologies and the relentless focus on core competencies have pushed companies to outsource a lot of their activities, leading to commodization and increased competition. Barriers to entry for copycats are lower than ever, therefore maintaining differentiation over a long period of time is now virtually impossible, despite trademarks or patents. Note that this phenomenon goes beyond what happens online: it is not uncommon to find clothes inspired by the latest fashion week in Zara or H&M stores before the actual designers are able to sell their original products.
Speed of execution is increasingly the only way to stay ahead of competition. This has some drawbacks, such as the focus on being first to market and getting scale over monetization or profitability (from Twitter to Xiaomi), and sometimes leaves the impression that you are offered a beta product that has been rushed to market. Digital products can improve daily from their Minimum Viable Productstatus, but many Kickstarter or IndieGoGo supporters end up disappointed with what they get.
Today's unicorns are platforms, not products
To work around these limitation and remain competitive against low cost me-too products, companies of all sizes are all about platforms and no longer standalone products. Value gets now created through stickiness of a platform rather than differentiated products. The equity of a brand is increasingly equivalent to the value of its ecosystem.
What is a platform ? In a platform approach a company's product operates as a facilitator and large part of the value is created by the participants instead of the company itself, which can be Facebook users, Uber drivers or makers of Apple-compatible accessories.
Again, nothing really new here as Tupperware or Avon sales have been operating this way for decades, the PC industry has thrived around the Wintel ecosystem, and Android and iOS have won the mobile OS war with their ability to attract and keep developers on their platforms rather than BlackBerry or Windows Mobile.
What is new though is that the platform approach have become the standard practice in the digital B2C space to compete for companies aiming to disrupt (another popular buzzword) the market, or create a new one.
Some of the most famous examples can be found in eCommerce (Amazon, Flipkart or Alibaba) or in messaging/social media (from Facebook to YouTube, Tencent or Snapchat). Online marketplaces such as Uber and AirBnB are currently some of the most prominent examples, getting as popular and powerful as Apple or Android.
Third party players: Ecosystems and Network Effects
- A prerequisite for a successful platform is the ability for a company to build a value proposition around an ecosystem and not only its own products. This means convince 3rd party companies to join and share value with them. In software this is usually done by publishing public APIs. Arguably, the most successful ecosystem is the one orchestrated by Apple, where you don't only buy an iPhone, you get into the Apple ecosystem of hardware, content and services.
In the mobile apps space, countless developers write apps for iOS and Android. Apple and Google provide the API, maintain the appstore and give back 70% of the revenue to the developers. Hence a platform can benefit but also become highly dependant on innovations developed by other firms.
"No single company can replicate all the innovative capabilities of the market."
- Another key component of platform is the ability to leverage network effects. For a thorough introduction to network effects and asymetric business models, I highly recommend the comprehensive slidedeck by Anu Hariharan at Andreesen Horowitz. In short, network effects happen is product or a service value increase exponentially as the number of users goes up. Long time ago it was the telephone line, then the fax machine and more recently Facebook
The key challenge of course is that in order to enter the virtuous circle of Metcalfe's law, a classic 'chicken and egg' problem must be solved first. Why should you install a telephone line if nobody you know has one ? In addition building a desirable product, "Growth hacking" is therefore a key activity for start ups: reaching critical mass is the necessary extension to first mover advantage and is usually seen as more important than effective monetization. That approach is sustainable in the digital domain as cloud services make it easy to scale to impressive level on the cheap: Whatsapp was able to serve 450 million customers with only 32 engineers, and Groupon or Living Social operating cost issues are only due to their huge needs for sales reps.
Only for digital start ups ?
However the trend towards platform also affects hardware companies. A vast majority on the start ups in the chart below from 2014 were pitching a platform, especially the most valued ones. A notable exception in the list is GoPro, and it currently pays the price of being a one-trick pony with slowing sales and lack of stickiness despite a powerful brand.
Literally everyone in the consumer electronics space is trying to replicate the successful model developed by Apple. For example Samsung acquired the smart home platform SmartThings and is developing services like Samsung Pay and LG recently introduced the G5 modular phone. Obviously investments are much higher than for a digital start up, and efforts can take years to materialize.
In Platform Revolution: How Networked Markets are Transforming the Economy and How to Make Them Work for You, Geoffrey Parker, Marshall Van Alstyne, and Sangeet Choudary explain that moving from a traditional 'pipeline' model to a platform involves three key shifts, which are quite suitable for agile start ups.
- Main activity moves from the control of limited resources (raw materials, equipments...) to an orchestration of intellectual property and interactions of the community of users and partners
- Efficiency does not come from optimization of internal processes (e.g. production yield) but through the ability to increase (external) network effects via the ecosystem.
- Value is contained by the whole ecosystem rather than individual products
More than a buzzword, the new normal for products
Platforms are not only the latest Silicon Valley fad for building unicorns, but they have become the new normal to build and sustain a strategic advantage. In markets where it is increasingly fast and easy for competitors to duplicate innovative products, often at lower cost, building and maintaining platform is arguable the best way to fend off competition. Like it or not, it is time to adjust to this new paradigm where even a great product cannot be successful for very long in isolation..,
Note: views expressed here are those of the author, Thierry Little.
About the Author
Thierry Lillette has over 15 years of experience across wireless technologies and Consumer Electronics devices with a unique blend of business acumen and technical savvy and a passion for breakthrough products that will ship in millions and delight customers. Defined and launched multiple high-volume and award-winning portable devices, including mobile phones, GPS navigation devices (PND),clean energy and now focussing on the connectivity chips that make all these products smart and useful. Experience in managing all steps of product life cycle and handling multiple branding / route to market combinations to deliver strong business results while delighting users on a global scale. Thriving in multicultural / international environments and interested in global opportunities in upstream product management & business development in the high-tech / consumer electronics or telecoms sector.
IoT platforms make the developer’s life easier by offering some independent functionality which can be used by the applications they write to achieve their objective. Saving them from the task of reinventing the wheel. Given here is a list of useful IoT platforms.
Kaa is a flexible open source platform licenced under Apache 2.0 for building, managing, and integrating connected software in IoT. Kaa’s “data schema” definition language provides a universal level of abstraction to achieve cross-vendor product interoperability. Kaa supports multiple client platforms by offering endpoint SDKs in various programming languages. In addition, Kaa’s powerful back-end functionality greatly speeds up product development, allowing vendors to concentrate on maximizing their product’s unique value to the consumer.
The Axeda Platform is a complete M2M and IoT data integration and application development platform with infrastructure delivered as a cloud-based service.
The Arrayent Connect Platform is an IoT platform that helps to connect products to smartphones and web applications. It comes with an an agent which helps the embedded devices to connect to cloud, A cloud based IoT operating system, A mobile framework and a business intelligence reporting system
Carriots is a Platform as a Service (PaaS) designed for Internet of Things (IoT) and Machine to Machine (M2M) projects. It provides tools to Collect & store data from devices, SDK to build powerful applications, deploy and scale from tiny prototypes to thousands of devices
Xively offers an enterprise IoT platform which helps in connecting products and users, manage the information and an interface to for product deployment and health check
ThingSpeak is an open source Internet of Things application and API to store and retrieve data from things using the HTTP protocol over the Internet or via a Local Area Network. ThingSpeak enables the creation of sensor logging applications, location tracking applications, and a social network of things with status updates
The Intel® IoT Platform is an end-to-end reference model and family of products from Intel, that works with third party solutions to provide a foundation for seamlessly and securely connecting devices, delivering trusted data to the cloud, and delivering value through analytics.
A votable & rankable list of these platform can be found at Vozag
Note: this page contains paid content.
Please, subscribe to get an access.
Note: this page contains paid content.
Please, subscribe to get an access.