Blog 1 – Functional Building Blocks of an IoT Platform
Introduction
When implementing an Internet of Things (IoT) application, companies have various options to choose from or build their own IoT platform. Below, we explain some of these options and the challenges associated with them.
Option-1: Build Customized IoT Platform using Open-Source Software
Custom build the IoT Platform from scratch using the open-source components that meet your current needs but have an eye on future business needs. The challenge here is: you yourself need to manage these open-source components and infrastructure. You need to “design for scale” to ensure that the solution meets your future needs.
Option-2: Build IoT Platform leveraging SaaS Products
Subscribe (instead of custom build) to readymade IoT Platform SaaS offerings (ex: PTC ThingWorx, Siemens MindSphere, SoftwareAG Cumulocity, Azure IoT Central). Let us look at the pros and cons of this approach.
- Mostly these services are boxed solutions and will be managed by a service provider. You need not worry about patches and updates at any time.
- Helps you quickly go to the market.
- Generally, these services may not offer you customization.
- These SaaS services offer “T-Shirt size” billing models. You may not have fine grain control on billing optimization.
- You will be locked with a specific platform. As you scale, increased monthly bills might be a concern. In future, migrating to a new platform may cause temporary disruption to your operations.
Option-3: Build Customized IoT Platform using PaaS Services
Custom build the IoT Platform using IoT PaaS components offered by leading cloud service providers like Azure IoT and AWS IoT. Let us look at the pros and cons of this approach.
- These PaaS components are cloud deployed and managed by the cloud service provider (Azure / AWS).
- These components offer horizontal scaling instantly by default.
- They offer “pay-as-you-go” pricing model, which is transparent, and billing is completely in your control.
- You can choose the right component of the right size, for the right purpose based on your current needs. When the time comes, you can upsize / redesign the component to meet your future needs.
- You need not stick with any single cloud component. You can build your services based on hybrid/multi-cloud components.
- You will have complete control on architecture, and you can tweak the architecture as your needs evolve. You can achieve better performance continuously.
Which option to choose, when and how?
If you are looking for a quick POC and Pilot of your planned IoT solution or a quick “go to the market” / if you are in initial stages of conceptualization of an IoT solution / if you are not looking for much customization – then choosing Option-2 (SaaS) makes sense.
If you plan to connect / estimate a really large number of device fleet, want to own customized and scalable IoT Platform, and want to have absolute control on the platform – then choosing Option-3 (PaaS) makes sense. If so, the obvious next question(s) would be:
- What skills and knowledge are required for designing an IoT Platform?
- What are the functional building blocks of an IoT Platform?
- What are the non-functional requirements we need to consider while building an IoT Platform?
- List of IoT PaaS services available from leading cloud service providers like Azure and AWS? What to use? When to use?
Due to the ever-evolving nature of industrial assets, smart devices, cameras, low power wireless devices and the wide variety of sensors and actuators, there is no one-size-fits-all architecture for IoT projects. However, some of the functional building blocks will be similar across IoT projects.
The goal of this blog in this series is to understand functional building blocks of an IoT Platform. In this blog, we will also discuss general design principles, as well as specific best practices and guidance for scalable IoT solutions. As part of this series, in our next blog, we will introduce you to Azure IoT Suite and AWS IoT Suite and help you build the right solutions with right PaaS components that are robust and scalable.
Simple and Functional IoT Architecture
Please find the simple and functional IoT architecture below. There are at least two distinct logical layers to consider when building an IoT workload.
- Device Layer
- Cloud Layer
IP capable devices can directly connect to the network over “internet protocol” and can communicate directly with the cloud. Surveillance cameras, connected cars, e-scooters, smart emergency buttons for elderly care, connected coffee machines / refrigerators / washing machines, connected vending machines fall under this category. Mostly these machines can connect to home Wi-Fi / on-premises LAN / 4G or 5G mobile data to interact with the cloud backend.
Non-IP devices (no sim card, no Wi-Fi, no LAN) can’t communicate directly with the cloud. It needs an intermediate IoT Gateway which is IP capable (using 4G/5G sim card, Wi-Fi, or LAN) to reach out to cloud. Sensors, actuators, industrial assets like PLCs, legacy assets like pumps, motors, compressors fall into this category.
LPWAN devices (such as LoRa, SigFox, NBIoT) use low power radio technology to communicate with the nearest base station / intermediate gateway. They can’t communicate directly with the cloud. Base Station / Gateway receives the RF messages from these devices and forwards these data packets to the LoRaWAN network server (LNS) / NbIoT server / SigFox server, which is connected through an IP backbone. LPWANs are commonly used in applications including Smart metering, smart lighting, asset monitoring and tracking, smart cities, precision agriculture, livestock monitoring, energy management etc.
Introduction to Cloud Processing and Edge Processing
The IoT devices and sensors generate lots of data, mostly raw data (may be binary, may be encrypted, may be unorganized), and usually this data is useless until it is processed. We need to process this data to derive some useful information. This meaningful information can be used to take corrective actions, predicting and preventing equipment breakdowns, reducing downtime and maintenance costs, improving the manufacturing processes, providing clean and safe living environment to residents of the city.
In an IoT architecture, data processing is a must. Now the question is where to do data processing. Do we need to do data processing on the device or on the cloud? In the cloud layer, you have an enormous amount of computer power available. In the device layer, you have a limited amount of compute power. You can process data at the device layer, but what you can do is limited by the processing power available on each IoT device.
Data is at the heart of an IoT architecture, and you need to choose between immediacy and depth of insight when processing that data.
- Choice-1: If you are looking for deeper insights: you probably require more intensive processing. If this is the case, then you need to move the IoT device’s raw data into a cloud-based platform that can bring several sources of data together (including business data, weather data etc.) and process these data streams together for deeper insights. But these insights will take time. This is cloud computing paradigm. One more thing worthy to note is: Here, in this case, you are moving entire raw data into cloud, you will end up paying more monthly data bills (recurring), and you need to spend more money for cloud services (recurring monthly subscription / usage charges). Hence, this model might not be sustainable.
- Choice-2: If you are looking for immediate information: then you need to plan the data processing near to the IoT devices. For example, some decisions can’t wait for deep processing. Did the boiler temperature cross the safe threshold values? Will the car crash? Do I need to take a left turn or a right turn? Will I hit the pedestrian? You don’t have time to send the raw data to your cloud servers and wait for feedback / recommendation / decision. You must process the information right at the sensor / right at the device / right at the gateway — at the very edge of the edge network—for the fastest response / quick decision to make. Now the obvious question is, is it always possible to process the data at the device level. Certainly not. Your device might be battery powered. In that case data processing at this level may eat up your battery extremely fast. Also, you may need to process multiple sensors data / multiple IoT devices data. Hence, it is wise to consider the data processing near to sensors and devices, but on Gateways / aggregation points which are more resourceful and might be AC/DC powered (or) powered over Ethernet. These gateways and aggregation points allows you to even use machine learning algorithms to scan for anomalies very quickly, so that you can identify impending maintenance problems that require immediate attention, and proactively notify / alert the shift supervisors, asset operators for immediate attention. This is “Edge Processing” paradigm.
So, the recommended best practice is to follow staged approach for data processing – which means pre-processing / quick-processing at edge devices, detailed processing at cloud layer. With this staged approach, you can preprocess the data, generate meaningful results (intermediate), and pass only those on to downstream cloud services. For example, rather than passing on raw vibration data for the pumps, you could aggregate and convert the data, analyze it, and send “only projections of when each pump will fail or need service” to cloud.
Yes, agree that you need to spend extra money for this, however this kind of staged approach brings several key benefits which are noteworthy.
- Reduced monthly data bills and monthly cloud charges, as you are sending only limited data (pre-processed), not raw data.
- Improved speed / Reduced latency / Real-time decision making.
- Improved security posture and privacy protections:
- Data resides near to the devices.
- Edge devices hold limited data sets, not complete data sets. Consider, for example, edge computing in a healthcare setting. Sensors collect a patient’s vital signs, which are then analyzed by an edge computing device. That device only holds those readings, no patient information. For some reason, if this device is hacked, hackers will get limited information (vitals), but no patient details. Vitals without patient information are useless. However, if the sensors send the data back to cloud servers where it’s stored with other information, including patient’s personal information, and that information is hacked, then that patient’s privacy is compromised.
- Improved reliability and resilience
- Edge computing continues to operate even when internet communication channels are slow, intermittently available, or temporarily down. This model ensures operational continuity even though the internet network is down.
Note: With the latest technical advancements in silicon technologies and 5G technologies and batteries, with the cost of electronics coming down day by day, the devices are becoming slimmer, and powerful. We started seeing smart & powerful products coming to the markets with good compute capabilities (good size of CPU & RAM, support for ML) best fit for “edge computing.” That’s why we don’t see any more device layer separate & Processing layer separate.
Functional IoT Architecture
Hope you understood the importance of device layer, edge computing layer, and cloud layer in an IoT architecture. Now, let us look at the building blocks of these three layers.
Functional Building Blocks of (Device + Edge Computing) Layer
This layer deals with physical devices (hardware and firmware), device protocols and embedded OS. Sensors, actuators, transducers, legacy assets, IoT devices, LPWAN devices, IoT Gateways and aggregation points are part of this layer. There are wide variety of device protocols (4G/5G, WiFi, NbIoT, LoRa, SigFox, BLE, ZigBee, Zwave, Thread, Modbus, HART, OPC-UA) available. Some are IP capable, and some are non-IP. Some are industrial, some are non-industrial category. Some are low-powered and constrained, some are power hungry and resourceful. Whatever the scenario, IoT Platform architecture should support these variety of devices, and IoT Platform should be device agnostic, protocol agnostic.
This layer is responsible for regular interactions with sensors and actuators, PLCs, OPC-UA servers, Historians, child devices. This layer is responsible for scanning the child devices, pairing / connecting, telemetry data collection, local data storage, local data processing, local data visualization, actuator control, processed data routing to cloud platform. Let us understand the key functional building blocks of this layer.
| Edge IoT Application | An IoT application running at the device / gateway has following typical responsibilities
|
| Edge Protocol Adapter | This module typically serves as a bridge between proprietary device protocols and standardized applications protocols such as MQTT or LWM2M. This service is generally deployed in IoT gateways. For example, look at the following scenario. IoT Gateway communicates with industrial PLC using ModBus protocol and collects the data, and makes the JSON packet, and sends to cloud using MQTT protocol.
|
| Edge Data Normalization | This module enables the conversion and standardization of multiple sensors / child devices data at the IoT edge into optimized and structured JSON data packets before sending to cloud / before storing it locally.
Additionally, edge may collect sensor data at high refresh rate (once in few milli-seconds to seconds based on measurement frequency settings), and may aggregate into a single packet and send to cloud once in few seconds to minutes (based on ingestion frequency settings) |
| Edge Event Processing | This module provides the ability to execute actions including external callouts, notifications, and generating alerts / alarms based on the business rules (simple threshold-based rules). Basically, this is a rule engine with IFTTT (IF – This – Then – That) / IFTE (If-Then-Else) policy implemented. |
| Edge Analytics | This module provides the ability to do telemetry data aggregations, trend analysis, anomaly detection, performance monitoring based on the continuous IoT data captured locally. |
| Edge Data Storage | This module provides either ephemeral or persistent storage of asset data at the IoT edge. Edge data storage can be used as a short-term storage engine during periods of intermittent platform connectivity or as a longer-term storage engine for edge-based analytics or monitoring. |
| Edge ML | This module allows analytical inference to be performed on pre-trained models on an edge device, closer to the point of data ingestion. Edge ML is commonly utilized to perform real-time anomaly detection, image recognition, speech recognition, data traffic optimization, and more. The training of ML models generally takes place in the cloud. Edge ML enables edge devices to make operational decisions autonomously without requiring a connection to a network or central processing hub. |
| Edge Security Agent | We can’t physically be present besides the devices always. Devices are distributed geographically. Hence, some kind of device activity monitoring tools are a must.
This module is responsible for auditing the user activity (failed logins / repeated failed logins) on installed devices, device file watcher, device port activity and inform cloud in real time about discrepancies / malpractices noticed, so that IT team / field team can take necessary actions in time. This is an important module. |
Functional Building Blocks of Cloud Layer
Your core IT infrastructure that includes IoT Hubs, message brokers, data routing services, event hubs, enterprise grade rule engines, stream processing engines, data lakes and notification hubs will be part of this cloud layer. This layer is responsible for feature rich intuitive dashboards and data visualizations. These powerful IT systems can analyze, manage, and securely store data. This layer can execute a more in-depth analysis and combine your sensor operational data with data from other IT data sources (ex: weather data, business data) for deeper insights. Let us understand the key functional building blocks of this cloud layer.
| Device Management Core | Device Management: This sub-module is responsible for lifecycle management of devices / gateways / access points / aggregation points (provision / reprovision / deprovision / connect / disconnect / enable / disable).
Connectivity Management: This sub-module manages the field-to-cloud bi-directional communications. MQTT, AMQP, HTTPS are widely used IoT protocols between devices and cloud. Device Twin Management: This sub-module helps you maintain all IoT device metadata including device current state (OS version, Firmware version, configurations) and future state. If enabled, this module maintains the historical state in a SQL-type asset database. Device Operations: Through this sub-module, one can initiate device operations remotely (ex: firmware upgrade, reboot, remote secure tunneling to troubleshoot the device). |
| Software and Firmware Repository | This repository acts as a centralized hub for IoT device software and firmware. Latest firmware versions and patches to be maintained here. |
| Data Ingestion and Routing | This module enables IoT devices, aggregation points, and gateways to ingest data (telemetry / events generated at the edge / heartbeat notifications / battery information / live location ) to IoT Platform.
MQTT / MQTT over Secure Web Sockets / HTTPS – these are the 3 more popular IoT protocols used for data ingestion. The Routing module allows these ingested messages to pass through a variety of on-platform or off-platform services. |
| Data Processing | This module offers both real time processing and batch processing capabilities.
Real Time Processing: Involves continuous input, process, and output of data in a short period of time. Examples could be aggregations over short period of time (15 minutes average, sum, max, min, median, mode). Here, latency is the main design consideration. Batch Processing: This module helps with processing large volumes of data efficiently. In this model, first data is collected, entered, stored, and then processed. Examples could be city wide daily averages, yearly averages. Here, throughput is the main design consideration. |
| Data Storage | This module allows the persistent storage of IoT device data typically in time-series formats and facilitates querying the IoT data-based filters. No-SQL data stores and Hierarchical Data Lakes are highly popular for IoT Data Storage.
When it comes to data storage, all data isn’t equal. All kinds of data streams (device raw data, real time insights, batch processing outputs) do not need the same level of protection or ease of access. Hence, it is better to define data storage strategy. Hot Storage: Store the data that must be “accessible immediately” in the hot storage. For ex: mission-critical data, last 15 days data. Hot storage offers better latency. Cold Storage: Data that is rarely used or accessed is a good candidate for cold archival. This is typically information that must be retained for compliance purposes. Cold storage offers better pricing. |
| Cloud Rule Engine | This module provides the ability to execute IFTTT rules (IF – This – Then – That) / IFTE rules (If-Then-Else) on stored machine data. The rules can be based on threshold values / location / moving averages / or other operator- or administrator-defined parameters. |
| Cloud ML | This module facilitates ML model training, deployment, and enables real-time analytics and inference. Common use case scenarios are predictive maintenance, complex classifications, and more. |
| Alerting and Notifications | This module helps in pushing events / messages to operators, administrators, or external systems in real time. More specifically, this module is responsible for sending Email / SMS / WhatsApp / Teams / Slack notifications based on the severity of the event (Error, Info, Warning, Critical). Critical alerts are called alarms, and they should be intimated to operators asap for required actions. |
| External Integrations | This module helps in integrating selective IoT data with external systems / platforms including ERP, CRM, Asset Management Systems, Connected Field Service Applications / Trouble Ticketing Tools, and others using an API or other connector mechanism based on business rules. |
| Data Egress | This module facilities data retrieval programmatically (based on time series filters and queries) from on-platform data stores. |
| Secure APIs | Data APIs: Provide programmatic access to data stored within the IoT platform as well as live data received from IoT devices.
Management APIs: Facilitates configurations, operations and monitoring of the IoT platform. |
| Authentication and Access Control | This module provides identity verification and identity management for all platform-connected elements including APIs, Users, Admin UI, Operator UI, Devices, Gateways, and platform-provided services. For added security, this module should support multi-factor authentication for both users and devices and support multi-tenant and customer-of-customer models. |
Non-Functional Requirements of an IoT Platform
We have discussed in detail the functional building blocks of an IoT Platform. Now let us investigate non-functional requirements of an IoT Platform.
Scalability: First, you need to build IoT Platform with scalability in mind. The amount of data that you will collect over time will take on enormous proportions and you will need a platform that can accommodate this in the long run.
High-Availability: You need to ensure that you have high availability at any given time. You need to eliminate a single point of failures to ensure continuous operation and uptime at least 99.9% annually. The recommendation is:
- Build redundancy at all critical infrastructure layers.
- Do data replication across data layer.
- Allow the system to monitor itself for failures and non-availability of service. Allow failover to backup system in case primary service is down.
Security: Threats and bad actors continue to evolve to find new ways to breach data security, disrupt reputations and cause financial loss. That is why, when you are designing an IoT platform, be certain and design stringent security policies from the start—security measures that are robust, certified, governed and under constant scrutiny. While designing an IoT Platform, at a prominent level, you need to consider the following security measures from the beginning.
- IoT Platform should mandate TLS 1.2 for IoT data transfer from devices to cloud.
- Secure APIs: IoT Platform should not allow any kind of direct access to the internal code and functions. All interactions should take place through a set of secure public-facing APIs, which expose every function of the platform.
- Physical Security: IoT Platform should prevent unauthorized access to IoT devices (for ex: redirect data to some other server / manipulate data in between / read credentials from the devices / change device configuration).
- Monitor Device Activity: IoT Platform should enable instant device defender notifications to IT team / field team in scenarios like (failed logins / change in port settings / USB inserted – removed / file changes). Ensure that each device has its own identity (certificate / keys).
- Find out compromised devices quickly: Implement polices so that IoT Platform can detect rogue / compromised devices instantly, eliminate them from main IoT pipeline and send them to quarantine state / isolation gracefully for further examination.
- Network Security: Ensure HTTPS is implemented from devices to cloud applications.
- Application Security: IoT Platform should take the following steps.
- Proactively notifying users about devices running outdated software/OS versions
- Enforcing smart password management (e.g., mandatory default password changes).
- Disabling remote access to a device unless it is necessary for core functions.
- Disabling unused ports
- Support for Multi-Tenancy: IoT Platform should support physically separating the data for each tenant.
- Integration with ITSM and SIEM tools: Ensure IoT Platform architecture facilitates integration with industry leading ITSM and SIEM tools.
Flexibility: Finally, you will need a system that is flexible enough to accommodate quick and frequent changes. As your architecture evolves, or your business needs change over time, you will need to iterate quickly without breaking the existing architecture. The platform should be easy to maintain and manage.
Conclusion
In this blog we have identified functional building blocks of an IoT Solution. We have clearly identified edge requirements and cloud requirements. We have discussed the non-functional requirements we need to consider while designing an IoT Platform.
eInfochips is a trusted Systems Integrator (SI) renowned for its extensive expertise in Azure and AWS IoT Platform-as-a-Service (PaaS) components. With a deep understanding of these platforms, eInfochips has successfully designed, delivered, and deployed numerous IoT solutions across diverse domains, including the food industry, surveillance industry, medical devices industry, and more. eInfochips’ track record of delivering high-quality solutions in various domains positions them as a reliable partner for organizations seeking to implement robust and scalable IoT solutions.
Stay Tuned
In our next blog titled “Manage – Monitor – Control billions of IoT Assets using AWS IoT Suite / Azure IoT Suite,” we will investigate AWS IoT Services / Azure IoT Services, and we will learn how to build a scalable IoT Platform using Azure / AWS IoT PaaS components.
