Building applications has gotten easier. However, as the number of devices rises, the large and varied stores of data that these applications produce have become difficult to manage. IoT and business leaders need greater agility, scale, and consistency from IoT infrastructures to manage thousands of IoT devices. There is an urgent need for new business processes and systems to make sense of the data. This is where cloud storage and data services innovation can help drive business value. An effective IoT device management platform is a must for any successful IoT solution.

That’s why we’ve invited Marcin Nagy, IoT Product Director at AVSystem, to contribute to the eighth article in our series “How to create a successful ecosystem for your IoT project”.
Marcin will be discussing the challenges of scaling IoT solutions, choosing a device management platform, and an application enablement platform to facilitate the flow, organize, understand and make better use of the data.  He is going to share his advice and best practices about “How to scale your IoT solution thanks to data and device management systems”.

If you’d like to read more inspiring articles, just click here. 
 

Hello Marcin, In a few words, can you explain what is the mission of AVSystem and your role in the IoT ecosystem?

AVSystem is at the forefront of IoT Device Management, which is a central part of today’s IoT ecosystems. Device management alone is about managing, scaling and operating devices remotely.  We go far beyond that. We are problem solvers. We focus on IoT Ops.

‘DevOps’ is derived from Development and Operation and is the talk of the town in IoT circles at the moment. Ops teams are responsible for making sure that the infrastructure is being maintained properly.
We provide them with a platform and tools to make sure their IoT devices can be updated and that the IoT solution is working reliably and is stable and secure. Our solutions can alert DevOps if something in the system is out of order, give them clues to narrow down the issue and help them re-stabilize the system.  

We automate processes and help companies to develop ecosystems of millions of connected devices thanks to several building blocks:

• Our Coiote IoT Device Management platform provides scalable and industry-agnostic IoT environments to speed up any IoT deployment with standards-based IoT device management as well as extensive data management. It uses the Lightweight Machine to Machine (LwM2M) protocol to speed up IoT deployments by delivering IoT device management functionalities out-of-the-box.
• Our Coiote IoT Application Enablement platform uses existing infrastructure to create new supplementary services for various IoT verticals without the need for custom software development for specific use cases or projects. It collects data from all sources —devices, assets and platforms— processes it, aggregates it and normalizes it to provide users with analytics and data visualization that will help them apply business intelligence, perform custom event-based actions, and rapidly develop new IoT applications      
• Anjay LwM2M SDK, is a very lightweight client library, an open-source SDK that helps vendors of the IoT equipment to implement support for the Lightweight Machine to Machine (LwM2M) protocol in order to easily create scenarios for automated interactions between systems and devices in the Internet of Things environment.  

Conceived 7 years ago, Lightweight Machine to Machine (LwM2M) has become a popular device management protocol on the IoT market. However, global cloud solution providers such as Microsoft Azure, or AWS are still using MQTT (Message Queuing Telemetry Transport), a very popular and widespread communication protocol that, despite being an open standard, does not specify a generic device model, making it in practice a proprietary vendor —and platform—specific solution. This means that the user will have to go to great lengths to efficiently manage his devices via MQTT, often being stuck with one vendor throughout the entire project or forced to create firmware updates or any other management features from scratch. 

At AVSystem, we believe that LwM2M is the future of IoT as it adds a device model structure on top of the transport layer that guarantees interoperability. It offers ready-to-use standard sensor objects, connectivity monitoring, remote device actions and support for firmware over-the-air (FOTA) and software over-the-air (SOTA) updates. To facilitate the market adoption of LwM2M, we developed Anjay LwM2M SDK. It is an open-source tool that makes life easier for developers who want to start building their client right away with the help of multiple code samples, extensive documentation and easy-to-use API.    
 

What kind of companies come to you and why?

Most of our clients are large companies. We have a lot of critical communication systems, such as traffic operations for example, where it’s essential that the information is delivered reliably and with the smallest latency possible. We also work a lot with logistics and asset tracking clients.

As of today, not many start-ups are using Lightweight Machine to Machine because the widespread offer features mainly MQTT and there is not much awareness of the importance of open standards among them. However, big players are interested. Fortune 500 companies that are mature, large and innovative. They believe in open standards. They believe in unified ways of managing devices that LwM2M guarantees.

Some of our clients or prospects had been using the MQTT protocol but they were having problems with unifying all the data generated by their devices. In fact, they had to develop lots of specific protocols as a workaround or teach their ops teams 5 different types of MQTT operations which caused an operational nightmare for them. This is why they decided to move onto LwM2M. 

In practice, it is very easy to migrate to LwM2M, as there are no technological barriers. More and more hardware vendors natively integrate the LwM2M stack in their products. LwM2M is IoT-focused, very well optimized in terms of device flash usage, and, due to superior communication performance, it offers a small carbon footprint. What’s more, from a communication aspect, LwM2M also offers a possibility to transmit data over non-IP networks. Non-IP networks are more energy-     efficient because there is no transport layer. The transmission is quicker resulting in energy savings. At the moment, Anjay is the only LwM2M client on the market supporting communication in non-IP networks. 
 

What kind of considerations are we talking about with regard to the choice of a device management platform? What do we need to think about?

First of all, you need to consider the potential scale of your deployment in the long term, and think where you are going to connect your infrastructure. Is it enough to have a centralized infrastructure for all your traffic? If you have a lot of devices spread globally across several geographical regions, one server may not be enough because there would be too much physical distance between the infrastructure and the device. The larger the physical distance, the longer the transmission time. The longer the transmission time, the higher the energy consumption (read our article "The impact of the communication technology protocol on your IoT application’s power consumption" to find out more). So the question here is: how are you going to design your system to be scalable without impacting your product’s time-to-market?    

The second question is about the power supply of your device. If your device uses a battery then you should think how to optimize the battery usage to maximize the lifetime of your device and reduce long-term operational costs. If you have a power supply, perhaps you don’t need to be so concerned about it.      

A third question to ask is (a typical question for any IoT deployment!) how do you make sure your system is secure and how are you going to update it?

And finally there’s the question of monitoring: How do you make sure your devices are working as expected, with no issues and behave as they should? How will you be notified in case of failure?

You need to think about your device management platform very early in your project. If you believe in what you are doing, you can assume that there will be a point where the number of devices deployed in the field will be large, and you’ll still need to manage them. You need to be prepared for this. Without it, can you imagine logging in and doing operations on 10 different devices manually? It’s already complicated with 3 devices! Don’t deploy anything into production before thinking about device management first.
 

What are the main problems encountered by your clients when choosing their data management platform?

We are strong believers in cloud systems. SaaS business models are very popular and easily understood but there remain some hesitations to adopt them because of potential unpredictability of costs, lack of control over the infrastructure, as well as business problems of a service provider or legal boundaries. Some regulations may forbid using cloud and request the data to be kept within the customers’ premises. That’s one of the challenges.

But I think engineers will agree with me that one of the biggest challenges, if not the biggest challenge is scaling big data.

Cloud system providers are good at providing data warehouses, data analytics tools, infrastructure scaling tools and handling big queries. Cloud infrastructure is managed, maintained, and scaled by them and they are doing a great job at this. If you have everything in your own cloud then it’s easy. You can store data in these big data warehouses and take advantage of cloud services to build your system.

But if for some reason you can’t deploy solely in the public cloud, you also may consider deployment on premises. Then, you need to make sure that your cloud is agnostic and think how to address the challenges of system scalability on your own.
Some of our customers want to run our platform within their own cloud infrastructure, which is less complicated than an on-premise deployment, but there is more operational overhead that falls on the customer —not to mention the system operation learning curve. This is why you need to consider these two scenarios and think about how you are going to bridge these two worlds.

The amount of data to transfer from devices matters as well. Especially if you are using cellular connectivity, the monthly transmission volume is often capped. If you transmit too much, you might have to upgrade your subscription. 

If you are using WiFi to connect to the Internet then volume is not much of an issue. But you must be careful with the amount of data that you send to the cloud. The more data you store in the cloud, the higher the operational costs. So, the best way to go is to implement some intelligence…

Let’s take the example of Rolls Royce and their aircraft engines. These devices are very sophisticated and contain lots of components. Each one of these components is monitored and connected to a gateway located in the engine itself. The components report tons of data about how they operate. The gateway is a very simple intelligent system which receives data from components and processes them. If a component receives information that isn’t critical, it is processed at the level of the gateway. If it’s a bigger issue, it’s immediately reported over the satellite to the operational center where the engineers can investigate the problem. This way the system is filtering out non-critical information so that only the most important information is transferred. That’s what edge computing is all about.

There are also energy considerations to take into account. Indeed, bandwidth and energy consumption are closely related. The more data you need to transmit, the longer the transmission, the more impact on the bandwidth and the greater the impact on the energy consumption! So the idea is to keep the transmission window as short as possible.

For that, you’ll need to think about the physical distance between the device and the infrastructure. Information travels at the speed of light and the speed of light is constant. So if the device connects from far away, the transmission time to the cloud will be longer and the energy consumption higher.

To minimize it, you need to make sure that the cloud is as close as possible to the device and that you are able to direct the data to the nearest cloud instance. You may therefore have to deploy several cloud instances. For example, let’s say you are deploying devices all across America; you’d need to think about establishing a data center on the East coast, a second data center on the West coast, and maybe a third one in the Midwest. Then, you’ll need to make sure that the system recognizes the location of the device and selects a cloud instance for the device, optimizing for the smallest latency.  
This obviously works if you have battery constraints. But there is also the cost of establishing and operating multiple cloud instances and it might be higher than the increased cost of energy consumption.  In the end, that’s a business question to answer. Generally speaking, when it comes to bandwidth and energy consumption, and you work with the constrained devices, LwM2M is a protocol that is a better choice than MQTT. LwM2M optimizes data transmission and energy consumption better. Furthermore, it also gives you an option to use it in non-IP networks. Using this option allows you to save bytes on IP and UDP layers and as a result it further reduces the amount of data transmission and energy consumption.    
 

If you had to give some advice to someone looking at choosing the best network and building a successful project, what would it be?

1. Try to think long term.  
2. Try to use as many open-source solutions that have broad industrial usage as possible. That will help you reduce your time-to-market and if others before you have used the solution, you can assume that most of the issues have been discovered and fixed.
3. Think about security, it’s one of the central questions in IoT now. Make sure that your devices, your transmissions and your data are secure.
4. Think about how you are going to operate the system. I may be biased, but I think you should try to go for the Lightweight Machine to Machine protocol and see what you can get out of it. I really believe that it’s the best device management standard.  
5. Choose the data orchestration platform that is the best for your use case and your market segment. It’s a case-by-case choice, all the platforms are quite similar, you have to find the right partner for your vertical. Because your partner needs to understand your needs.
    

Do you see any trends in your market that you’d like to tell us about?

I hope that time for the Lightweight M2M’s market domination will arrive soon! We are seeing an increase in interoperability questions, which makes me think that we are only at the very early start of the Lightweight Machine to Machine’s massive expansion.
 

Thanks a lot Marcin!