Define a Technical and Business Strategy for your IoT Projects
Every successful IoT strategy must include two sides of the same project. Technical aspects that ensure functional, as well as the business aspects that ensure profitability.
At the core, IoT is a collection of physical assets equipped with sensors. Sensors that measure data and trigger prior defined business values. Yes, it matters what physical assets and sensors and protocols are in use but at the end of the day, the whole project is a business-driven solution.
1. Define - Outcome & Success
Many people are aware of IoT and consider it as the “NEXT BIG THING”. They do not want to miss out and "profit" from all the growth opportunities they heard about. They want "IoT" - whatever "IoT" is.
Like with every other project, there are no shortcuts. An IoT project is like every other project. It involves planning, budgeting, development, ... and much more before harvesting its benefits.
The first question to be answered is:
1.1. How does success look like?
Answering this question defines the direction of the whole project. Simultaneously, it raises other questions that must be addressed:
- Where to go?
- Who or what do we need to get there?
- In what time frame?
- What are the milestones on the way?
- What are the KPI’s of the project/milestones?
People often freeze up when it comes to this type of questions.
They are afraid of giving the wrong answer and dance around the decision.
Often delaying it or pushing it onto other members of their team.
It is important to keep in mind that answers provided today are based on today's knowledge and today’s understanding but can be adjusted tomorrow.
2. Connect - Network & Data
At the end of the day, a fleet of assets will generate and transmits data over the network to a server/application. The second most important aspect which needs to be defined is a good network and data structure. The challenging part is to define a realistic granularity of what is necessary (must have) and what could be done on top (nice to have).
Let’s assume an asset transmits for tracking its GPS position. The GPS data by itself (payload) has only 6 Byte and one would assume we can send this data as often as possible. But the reality is a bit more challenging.
- Depending on the IoT protocol, the payload will be encapsulated in an additional 40 to 1500 Bytes of headers, checksums and connection information. Let’s assume for this example we use an average message of 300 Byte for our project. Our 6 Bytes of GPS data, just increased to 300 Bytes. 6 Byte → 300 Byte
- The data should be transmitted many times a day to increase the accuracy of the asset position. Transmitting the position of the asset every 10min over a period of 24h results in 144 Messages. The total data consumption grows again. 300 Byte → 43.200 Byte
- Most businesses use a monthly payment cycle and calculate the data consumption over the whole period. For an easier calculation, we assume a 30-day cycle which increases the transmitted data to 1.296MB. 43.200 Byte → 1,296,000 Bytes or 1.296MB
- At the end of the day, the project will have more than a multitude of assets. Therefore, the data must be multiplied again. Let's use IoT benchmark of 100k assets (used to compare IoT solutions against each other). This leads to a total data consumption per cycle of 129,600 MB per Month or 1.56 TB per Year. 1.296MB → 129.6GB per Month → 1.56 TB per Year
- Last but not least, this is only “GPS” data. An IoT project will require also other parameters like battery state, temperature or humidity. These parameters increase the payload size once again and the calculation starts from the beginning.
As a result, it's critical to define not only the network architecture but also the protocols that will be used.
Because every bit transferred must be paid for. To the telecom for wireless assets connectivity, the cloud storage to manage the fleet's data or both.
3. Automate - Protocol & Communication
IoT is based on years of industrial automation. It includes both "old-school" protocols as well as modern, more efficient protocols.
Some IoT protocols have a payload restriction (e.g., Sigfox, a max payload of 12 bytes and 144 messages per day), while others, such as TR-069, transmit not only data but also a significant overhead (headers).
The protocol overhead is not the only criteria to be considered. Another very important aspect is the payload itself. The LwM2M protocol for example demands a very strict payload definition. It takes additional effort for the initial implementation but once set up, it outperforms other protocols through its high automation and compression capabilities.
On the other side, the widely popular MQTT protocol provides only subscriber management. All other functionalities (e.g.: asset management, updates, data definition, automation, …) must be developed on top of it.
Using an IoT protocol utilized by the whole IoT industry is more cost-effective than inventing your own IoT protocol and forcing everyone else to conform to it.
Reinventing the wheel Is an expensive undertaking
4. Build - Assets & Logic
Never before in human history has an IoT project been deployed that operated flawlessly from the start and required NO tweaks or updates.
Sooner or later every project will meet new requirements and need to adjust to them. For example, transmitting data in a different interval (granularity) or updating the firmware of an asset due to security risks.
Even if changes and updates are offered from a Hardware & Software point of view, they must be planed as well from a Business point of view. Manage upcoming work, schedule changes and ensure that it is executed based on the project specifications.
The most neglected topic in this category:
How "long" will it take to update/replace one asset?
Let’s assume the assets can't receive updates over the air and requires manual work. A manual replacement effort that requires 3 minutes of work per asset, results in years of work when considering a fleet of 100,000 assets. Not even calculating the travel times to access every asset.
Said that not every issue is solvable with software updates.
Manual intervention is sometimes inevitable and MUST be planned into the lifecycle of every solution.
This applies in particular to assets that are battery operated. Sooner or later (depends on the design and usage of the asset) the battery will be drained and need to be replaced. This might be a very long undertaking. Based not only on the size of the IoT fleet (amount of installed assets) but as well on the architecture of an asset.
It's possible that installing an asset will take less time than replacing its components (uninstall, open, replace, reassemble, install). Installing 100 assets every day will require an equivalent replacement effort, or a portion of the fleet have the risk to be unavailable.
Coming back to the logical software functionality of an asset, the recommendation here is towards assets that are smart(er) and configurable. Smart assets that are can execute a higher level of logic than just measure and transmit data.
Using the previously described GPS data transmission as an example. GPS information is only needed when the position of the asset changes. In other words, the position of stationary assets is neglectable since the same compared to the previous position.
Smart assets that are configurable to execute this type of logic (data on-demand) enable the entire fleet to operate more efficiently
Another aspect to be considered is to reduce the number of messages transmitted by the asset. This will immediately increase the battery lifetime. However, this approach reduces at the same time the accuracy of measured data and is not always doable from a business point of view.
Having smart assets enables the fleet operator to use one or multiple workarounds:
- Reduce the number of sent messages during the "inactive hours" while keeping the same message pattern during "active hours".
- Measure data at predefined intervals but bundle multiple measurements into one message
Optimizations like these enables the fleet to adapt to changing circumstances. For example, using the asset as planned but changing the assets behaviour once the battery reached a critical level.
5. Present - Application & Enrich Data
The final factor for a successful IoT strategy focuses on the server-side application. The following "Must Have Criteria" should be met by any good IoT application, to ensure basic asset and data management.
- Ensure that the predefined success, from the technical but even more from a business point of view can be achieved.
- Integrate into existing networks and support the selected IoT protocol
- Ability to manage a growing fleet of connected assets/transmitted data.
- Provide a possibility to extend its logic, on top of the "standard" asset/data management functionality
- Present the data in an easily understandable manner.
Overall, providing an overview of the whole fleet, as well as the ability to dig deep and configure one single asset/sensor.
Fulfilling these "Must Have Criteria", will ensure basic assets management functionality. Depends on the size and stage of the project these might be enough.
Going one step further there is the second stage of functionalities to be considered. Functionalities that come in handy once the fleet of assets reaches a certain level - more than 1000 assets. Managing these amounts of assets outgrows the capabilities of a human being.
A professional IoT Application should furthermore:
5.1. Work for you
It should inform the user by itself about changes in the fleet, for example, dangerous battery levels or low signal strengths. This is achievable by parameter monitoring, Notifications and periodic reports.
5.2. Provide multiple interfaces - IoT protocols and API's
This functionality is very useful once the project has been running for a while and assets must be replaced. For example extending the rollout, switching to a newer model or even to a different manufacturer.
For example, an external CRM's can enrich the collected data furthermore and fill the missing gaps (e.g.: What asset (ID) belongs to what customer?)
5.3. Extended logic and handlers
Extended logic and handlers enable the IoT Application to act upon different states. Take action when circumstances change and trigger timely changes.
5.4. Virtualization
This functionality is extremely useful when dealing with assets that ...
- ... are supplied by multiple manufacturers
- ... are new/old - at some point, your new assets will become "legacy assets" for newer projects
- ... use different Firmware
- ... have different configurations/updates installed on them
- ... us different IoT protocols but require the same logic/functionality
- ... have multiple assets installed in one "Thing". For example, a cooling truck uses one asset to report the state of the truck itself and another one that reports the state of the cooler.
Conclusion
By now you have probably realized (as shown in the diagram above) developing a successful IoT strategy one step at a time is not impossible. A successful IoT strategy must consider all aspects of the solution simultaneously while making sure that all of them are compatible with one another.
A chosen IoT protocol might fulfil all network requirements but hinder fleet automation.
- Or the TCO (Total Cost of Ownership) outgrows the market expectations/Business Model.
- Or legacy hardware/software limits future use-cases.
It is therefore important to always keep in mind what was mentioned at the very beginning of this article.
Decision made today are based on today's knowledge and understanding but might need adjustment tomorrow.
IoT is a fast-paced industry and it's a challenge to stay on top of everything. If you would like to get some help developing your successful IoT strategy please let me know - always happy to help out.
Top comments (1)
very nice!! thanks 👏