IoT Platforms: Exploring 10 Dimensions of the IoT Technology Stack
This blog was co-authored by Jarrod Luker, Julian Dale, and Jamie Cooley.
The Internet of Things (IoT) is transforming society, economies, and businesses on a scale that could rival the tech boom of the late ‘90’s. Gartner predicts that IoT could have an economic value add of $1.9 trillion, and some industry estimates predict there will be 20+ billion connected devices online by 2020. Getting these “things” connected to the Internet, bringing value to society, creating and expanding economies, and generating profits for businesses is a race that many want to run. Getting started with developing an IoT device can be confusing and overwhelming, and choosing a platform to support that device can be an even more daunting task.
In this piece we will focus on the technical underpinnings of an IoT solution, introducing 10 dimensions of an IoT Platform. We are going to start by considering the use case, then we will go over the technical components, and finally the decisions you must make in order to implement an IoT solution.
The Path of an IoT Experience
Ten years ago, a smart home was something seen only on MTV’s Cribs and many homeowners only dreamed of owning. A connected factory line was expensive; requiring custom systems that many companies also only dream of owning. But now there is a shift in affordability mainly due to lower costs of sensors and actuators, wider availability of tools and infrastructure, smaller and more powerful processing units, and an awareness that has left society wanting more.
When starting a new IoT project, how can we ensure that we deliver more? Can we leverage existing IoT platforms to satisfy our need to connect “things” to the Internet and provide value to our lives and businesses? Or should we build our own platforms, possibly prolonging the initial product delivery, but forming an in-house foundation for future deployments?
Presumably, we are in a state where we have explored the demographics of our soon-to-be IoT product, proven its use case, and possibly even chosen hardware. It is important that you think through how your users will be interacting with your solution because your implementation approach can vary greatly depending on the use case. Will the solution be deployed in a home network, crowded enterprise network, in a remote location? The benefit that connected devices gives is the ability to share the state of device. Will your solution be sharing the state with other devices or human users? These questions all need to be thought out as they will ultimately inform the approach to your solution.
From a technical perspective the Internet of Things landscape is new and malleable, which means that standards are just now emerging and still competing. And since the field is still so new, navigating the technical stack can be daunting.
To help with this, we can now introduce a generalized model of an IoT system by considering the following questions:
- How do I connect this product to the Internet?
- What protocol do I use for communication with this product?
- Is this product’s connection secure?
- How can I save and analyze the data from this product?
- Is the data I collected secure?
- How much does all this cost?
- How quickly can this product become a part of my customers’ lives?
- Is my product driving my decisions for a platform, or are the platforms driving my decisions for a product?
|Solstice IoT Architecture Diagram 1:1|
Our model above shows the main features that will comprise almost any IoT project. Of course, specific platforms and applications will vary on how closely they follow this model, but this generality will form the basis of the discussion for “the IoT Tech Stack.”
Let's dig into the IoT Tech Stack...
10 Dimensions That Make Up the IoT Tech Stack
In the field of computer science we define security as the absence of availability. A secure system is one that restricts the availability of its services and data to only known and entitled entities. Vulnerabilities will be abundant as IoT aims to connect billions of devices to the Internet. The generation, storage, and analysis of data is essential to the IoT. Consideration must be given to protecting that data throughout the entire lifecycle of a product. Since IoT solutions are complex and contain many different clients and services, there are inherently many potential areas for failure and compromise. Device management will allow users to set policies for their uniquely-identified devices, controlling data collection and software updates. The network connection allowing these devices to send data to the back end will need encryption, while still being lightweight.
As an example, due to improper input validation in OpenSSL, the Heartbleed bug allowed hackers to extract highly personal information about web users from servers using OpenSSL. Even today, as many as 300,000 devices have not been patched, including many embedded devices such as webcams, printers, and routers.
Connectivity is the communication backbone of an IoT platform, allowing devices to communicate with each other and with the cloud. IoT products add value by allowing devices to share their state with users and other devices. In order to share state information, connectivity between the devices must be present. The connectivity option you select for your solution will also impact the power consumption of the device, so this decision is very important in wearable or battery operated solutions. We are going to briefly discuss the pro’s and con’s of the following connectivity solutions: BLE, Wi-Fi, Cellular, and emerging low power connectivity solutions.
If power consumption is a consideration, BLE (Bluetooth Low Energy) provides a low power draw. BLE is mature technology and is already used in a wide range of applications from FitBit to smart locks. The drawback from BLE is that the technology is designed to be a personal area network (meaning you are in the proximity of the device). If your solution needs to be enabled by the cloud, BLE is not a great solution. A workaround to getting your BLE device cloud access is to pair the BLE device with a device that has Internet access: this is exactly how Fitbit works. A Fitbit tracker connects to a smart phone via BLE and then the phone is responsible for sync the tracker’s data with the cloud, so that the user can then go view the data on the different clients, such as a web browser.
Wi-FI is a rather ubiquitous solution for local networking as you can already find Wi-Fi networks in most home and office environments. Wi-FI can be implemented as a wireless access point (most common application) to connect to a larger network or as a peer-to-peer infrastructure allowing devices to communicate on a local network. Wi-FI is an excellent solution when a battery is not involved as it requires more power than other options. WiFi is also a great solution in a home application because most consumers will already have support for the network. This advantage also carries over to an office environment, although you may want to consider how crowded the network is.
Cellular is another connection point for an IoT solution. Since the cellular network is based around a network of nodes to connect to, this network provides an excellent solution for devices that need to move or will be placed in remote locations. Cellular connections are similar to Wi-Fi in terms of battery consumption. A unique consideration with choosing a cellular solution is the network provider. Most traditional providers (AT&T, Verizon, etc) are simply not interested in selling small data plans because the metric used to evaluate success - ARPU (average revenue per user) - does not favor such plans. ARPU is great in the case of selling multi gigabyte plans to users, but in the case of IoT, large data packages are rarely needed. Mobile virtual network operators (MVNO) are great providers for smaller solutions. If your solution has a large scale, major providers such as AT&T or Verizon will provide more cost savings.
The increased demand and interest in IoT has caused the industry to start creating low-powered wireless networking solutions. One well known low powered personal area networking solution is ZigBee. ZigBee is widely used in industrial solutions where minimal power consumption is extremely important. ZigBee can be implemented in any number of networking patterns including the star, tree, and mesh patterns. SigFox is another low powered networking solution, but this differs from ZigBee in that SigFox is designed to be a wide area network. SigFox coverage is currently limited to Europe and San Francisco (but roll out of the network across the USA is planned).
Gateways provide physical devices with access to the cloud, and some hub hardware can continue to keep parts of the system running when cloud access is lost. They can also host local processing power to help relieve an IoT platform of compute-heavy real-time processing of data.
3. Interaction Model
An interaction model is a collection of rule-based actions taken as a result of an event. This is essentially the business logic in the platform. When an event is triggered, from either state change, chronological, or analytics, the interaction model determines what action is taken based on that event. For example, let’s say we are developing a smart watering system. This system consists of a moisture sensor that is monitoring the lawn and a sprinkler. When the moisture sensor doesn’t sense any moisture, the interaction model is what dictates that the sprinkler should be turned on. In this case we have an event and action. The interaction model is the mapping between events and resulting actions. When designing an IoT solution, you must define the interaction model before you can really start architecting a solution.
The software needed to take action can be included at any level within the entirety of the platform. Devices need rules to react to user requests or messages from the cloud. The cloud needs rules to react to messages from the user or results of analytic computations. And a hub might also need rules for device-to-device interactions.
4. Identity/Access Control
Each device connected to an IoT platform must be uniquely identifiable, allowing the platform to provide individual statistics on the device, access control, and over-the-air firmware and software updates. Identity and access control has a rather significant impact on the way the user will interact with the device. For example, can multiple users have access to a single device, or does access need to be restricted to a sole user?
In an IoT solution there are really two aspects to identity and access control. You must have a system to correctly identify a physical device and one to identify users of that device. You need to be able to uniquely identify a device not only to control it, but also to make sure that the system or user interacting with it has permission to do so. In the case of connected home products, you need to be able to ensure that only the homeowners can affect their devices, and others are restricted. For example, if you have internet-enabled smoke detectors installed in your home, you are going to want to make sure only you can control and interact with the device.
5. Message Broker
A message broker handles reception and delivery of messages between clients and the platform. The message broker commonly follows a publication/subscription model. Clients can subscribe to messages related to a particular topic. When a message is published on that topic, the message broker looks up to see which sessions are subscribed to that topic and delivers the message to those clients. For example, in the previous example of the smart watering system, the interaction model dictates that the sprinkler needs to be turned on, and the message broker ensures that those messages are delivered.
The message broker can also pass a message to external services such as email or push notifications. Depending on the solution, the message broker can either be a discrete software service or a physical bridge between devices.
This is the physical “thing” connected to the Internet. The device may consist of specialized hardware conforming to specific needs of the platform and software provided by the platform vendor. The device is what contains the sensors or actuators that provide the physical interface to your system. In the sprinkler example above, the moisture sensor and sprinkler represent the devices that are interacting with the physical world.
7. Device Model
The device model is a cloud-based representation of the physical device. This model description would include up-to-date state representations of the device in the physical world, allowing other features within the platform to take advantage of such information for rules-based processing, real-time analytics, or long term data storage.
8. Device Model History
This represents a historical record of device model events. A platform’s access to this record will provide real value in allowing analytics engines to react to the data gathered from the device’s surroundings. Also, this record will contribute to data visualization in the form of charts and models and allow users to observe trends and patterns, providing further insight to usage and creation of the interaction model.
An Application Program Interface (API) allows clients to interact with a platform. This could include any mobile device, a desktop computer, or even test equipment. An API is what gives other systems the ability to leverage and interact with the IoT system. An API also gives you the ability to create clients that correlate your IoT data with data from other unique sources.
10. Third-Party Integration
Building an API will allow you to integrate with third party solutions. This can be anything from a CRM system to a business insights platform. For example let’s say you have an internet connected vending machine (Solstice actually has one). This vending machine records when beverages are vended and current stock levels. We can take the vending data and correlate it with a beverage database to determine similar products to the most popularly vended products. This way our customers would have more options that likely fits their taste, and hopefully the vending machine will produce more revenue. We could use the vending data to integrate with a business insights platform. This could help us determine when the best times to restock are, or which products are not selling well and shouldn’t be restocked.
Full Grown or Home Grown
In any IoT-enabled solution, the platform plays a key role. The decision to use an existing platform, with potentially proven frameworks, standard connection protocols, end-to-end security, and advanced analytics, can be difficult but will most likely be the best choice.
But what about building your own platform? Choosing an existing one may add limitations to your product. The platform may lack maturity or the ability for expansion. Building your own is always an option, but there are some important factors to keep in mind.
Technology follows a predictable pattern of rapid expansion with many competitors, but as the technology matures, the industry generally assimilates into a few top leaders. This has happened numerous times, most recently with the introduction of the smartphone operating system market. At the beginning, we saw Apple, Google, Mozilla (Firefox OS), Ubuntu, Microsoft, and Blackberry all vie to enter and control the market. Years later, the market has mostly been absorbed by Google and Apple.
Within the context of IoT providers, we see two main approaches. The first approach is to offer the infrastructure that backs an IoT solution. The second approach is to offer a platform that already contains the considerations in this paper. Choosing an infrastructure provider will ultimately create more work as you will need to design and implement the IoT platform within that infrastructure. The advantage to taking this approach is that cloud based infrastructure is already matured, and the market is dominated by the largest providers: Amazon Web Services, IBM Bluemix, and Microsoft Azure. Choosing the platform approach should require less additional work, as the selling point behind these platforms is a one stop solution to IoT complexity. With a platform, you will be able to afford more time spent on designing the experience, and you will most likely reach the market faster. The issue with this approach is that vendors in the space are smaller and newer, much like the beginning of the smartphone OS market. This approach will most likely follow history, and we will see vendors disappear, get absorbed by other providers, and ultimately a few dominate providers will emerge. Since this market is still so new, it can be very difficult to determine which vendors will have the same fate as Apple and Google and which will disappear from the market.
The end-customer of an IoT platform will have different requirements based on the use case of their product. For example, a retailer developing a connected pacemaker is going to be searching for very different features than the developer of smart farming equipment.
The use case will ultimately inform the decision on how you should implement the concepts laid out in this paper. Whether you choose to implement your own solution or choose providers, you are going to need to make sure your system includes each of the mentioned components. Developing a solution yourself will give you lots of flexibility and control of each component, but you may want to choose a provider and spend your efforts focusing on differentiating your solution from others.
Want to learn more about navigating the Internet of Things? Read our IoT Playbook.
Ready to implement your IoT solution? Contact us.