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.
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:
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.
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.
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.
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.
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.
By signing up, you’ll be the first to hear about our news and receive exclusive advices.
We use your email address solely for sending our IoT newsletter. You can unsubscribe at any time using the unsubscribe button at the bottom of the newsletter.
What are the ATEX directives and the IECEx conformity assessment system and why do you need batteries that comply with them? #Saft #ATEX #IECEx
We teamed up with our partner, Deutsche Telekom, to take a look into the implications of low-power design in battery selection. #Saft #Low-Power design #sensors
Romain Cayzac, Technical Manager of the CE division in Poitiers, our R&D department, explains the various options and capacitors now available to IoT developers in our LSP range. #Saft #LSP #Lithium-Thionyl chloride
Brian Conlee, Applications engineer at Saft America, explains how Lithium Manganese Dioxide (Li-MnO2) batteries can meet your IoT device's power and pulse requirements. #metering #tracking #Internet of Things
Digital Twins solutions such as Deutsche Telekom IoT Solution Optimizer can help in reducing the time to market and creating less defective devices. Miguel Rodriguez explains... #IoT #Internet of Things #digital twin
Several IoT trends continue to gather momentum stimulating IoT’s prominence in 2021. Explore the IoT universe and how it's been impacted by the pandemic in our infographic. #IoT #Market #Statistics
In this article, we explores the various power options available and what what processes to apply when selecting a source of energy. #IoT #Internet of Things #Energy
Find out which IoT applications are more likely to be impacted by passivation, and which one will remain “passivation-tolerant”. #Saft #Battery #batteries
Self-discharge is an important factor to consider for IoT applications. Watch our video to find out about how self-discharge can impact the battery life of your device. #Saft #Battery #batteries
Lithium Thionyl Chloride batteries are used in many IoT applications and knowing how they work and their particularities will help you select the best options for your application. #Saft #Battery #batteries