Share This Page

ShareShareShareShare
01/01/19

Considerations for developing IoT Solutions

Overview

IoT is an area with significant use cases already, and a very large potential on the horizon. The considerations when building solutions on IoT expand for typical large-scale enterprise applications. This multi-part blog will attempt to cover considerations that are specific to building solutions in the IoT ecosystem.

Consideration 1: Proven architecture

IoT solutions typically align to certain patterns that are well-proven. These patterns align to the following aspects of IoT solutions:

  • Patterns on the edge: communication, management, security, intelligence
  • Patterns for ingestion: scale, loose coupling
  • Patterns for processing: extensibility, loose coupling
  • Patterns for actions: communication, integration

The first consideration is to leverage a reference architecture that already exists, and tune it for the desired domain and solution. One such approach to IoT architecture is the work that has been done by the IoT-A consortium. The reference model that this group has released is version D1.5. At Mindtree, we have built a solution that uses the best practices from the reference model, and married it with real-world considerations of our areas of focus. The reference architecture will serve as an accelerator for our IoT work. A subsequent blog series will explore the different patterns and architectural considerations for IoT solutions.

Consideration 2: The Right Topology and Protocol

“Things” are central to IoT (well, actually not central, but the edge…); so choosing the right way to connect them up is the most important part for any solution in this space. A number of factors need to be considered when choosing the topology and the protocol:

  • How many nodes are to be connected?
  • What is the range expected (for example, to cover a factory of a few square km, or a home of a few square meters)?
  • What capabilities should the nodes have?
  • What constraints do the nodes have (for example, battery, and temperature)?
  • What already exists in the landscape (for example, existing Wi-Fi connectivity)?
  • What are the existing security requirements?

These factors help identify the layout of nodes, and how they are connected. For deployments that have to cover larger areas, options include meshes and more recently, LPWAN-based systems. A typical topology is connecting nodes through gateways, instead of directly to the cloud middleware. This works to enable intelligence at the gateway, since nodes are constrained devices. An alternative is the emergence of IPv6, and 6LoWPAN that provide addressability at node level.

A partial comparison of protocols and applicability is depicted here.

15 considerations-for-developing-iot-solutions-protocol-comparison

Topology and communication are also governed by the kind of constraints – particularly with battery – that are applied. Typical approaches to conserving battery are by putting nodes to deep sleep and waking them up on interrupts, and using lightweight communication protocols, such as those based on UDP, like CoAP.

The gateway (sometimes also combined with nodes and with outbound communication stacks) is an important part of the topology. This is where there’s opportunity to build in edge intelligence, to execute local rules, or to aggregate data to reduce communication roundtrips. At Mindtree, we are building an Intelligent Gateway Platform which will act as a key facet of our solutions. Similarly, we believe that node software also benefits from modularity, and our Sensor Hub design aims to do just that.

We will have another blog that talks of what protocol you’d use, when, and what the implications would be.

Consideration 3: Middleware Platform Choices

Today, a number of choices exist on the middleware side, where all ingestion, processing, storage and integration is housed. There are open source choices like Kaa, and there are on-cloud providers such as Microsoft (Azure IoT), Amazon (AWS IoT), and IBM (Watson IoT). There are also players who expand on core infrastructure capability with more specific accelerators such as ThingWorx; and there are those such as SAP (IoT Foundation) that can be deployed on cloud and on premise. Each of these have strengths and weaknesses. A subsequent blog series will compare some of these platforms more comprehensively, but here’s a high-level snapshot of an initial comparison between some that we are focusing on:

Considerations-for-developing-iot-solutions-protocol-comparison

In general, we are seeing a lean towards cloud platforms, given their ability to scale and perform.

Consideration 4: Building for Scale

Non-functional requirements, as always, are the make or break of any system. In IoT, the number of potential devices, and the number of telemetry events they send are important to model, since they are required to establish the scalability for ingestion, processing, and storage. Typically, ingestion happens using queue brokers, and hence these need to be deployed for scale. Cloud middleware providers typically provide these as a managed service, so the scalability when using such cloud deployments is taken care of. For on-premise deployments, this needs to be done explicitly.

The other aspect of scale is in storage. While there is a tendency to log everything because “it might just be useful later”, it runs the risk of bloating up data that may never be used. This risk can be mitigated by identifying what grain would be reasonably useful; and model aggregation logic at the edge taking that into consideration, so the data that is actually stored is what will likely be useful in the future.

The third aspect of scale is that of being able to process at scale. Stream analytics are an important component here. The two key elements are the ability of such stream analytics components to scale, and to do just the analytics part, with the resultant actions being decoupled through the use of queues. Again, cloud middleware providers provide scalable, managed components which makes it quicker for implementation.

Considerations-for-developing-iot-solutions-protocol-comparison

For IoT, lambda / kappa architecture is also a useful pattern since there are both - the need to react in real-time and to build rich models and rules using historical analysis.

Consideration 5: Security

Unlike enterprise solutions where security can be reasonably boxed till the firewall, in IoT, security extends all the way to the node on the edge. The threat landscape therefore is larger, and has more vectors that need to be taken into account. A brief snapshot of the different considerations for the key blocks is given here:

Considerations-for-developing-iot-solutions-protocol-comparison

In general, security for IoT is a vast topic. There will be a series of blogs that will address this topic in greater depth – stay tuned!

Testing and Deployment

A key element of any solution is ensuring that it works – and not just on the developer workstation, but also on the field. In IoT, this is further complicated by the fact that “field” could actually be an actual “field” of paddy or corn. To ensure that an IoT solution works as expected, testing needs to be done (a) at various levels of maturity, and (b) to cover various aspects. As an example, for testing at different levels of maturity, if the number of unknowns is higher, testing should be initiated at a breadboard and lab table level, before mass-producing rugged nodes. Similarly, if the business case is yet to be made, it is important to build reasonable quality prototype boards and gather insights before getting into fabrication.

From a deployment perspective, as per the model that is intended, one needs to plan for a large number of devices in the field, and build in mechanisms to ensure device management, security, and device identity. Partnerships to provide on-ground support is as critical – if a battery dies, over-the-air (OTA) updates will likely not help a lot.

Considerations-for-developing-iot-solutions-protocol-comparison

From a planning perspective, the solution needs to be architected, developed, and planned in anticipation of success, and its companion, adoption scale. Engineering best practices with regard to automation, continuous integration (CI) and continuous development (CD), therefore become critical.

In Summary

IoT is an exciting field with a number of very interesting challenges to solve, and a wide-open plethora of possibilities. IoT solutions therefore need to be built right, to evolve and scale, along with the business imperatives they power. Stay tuned for many blogs on this topic!

READ

Let's Talk About Your Needs

Thank you for your submission. We'll be in touch.