Lack of resources or technical challenges are often hurdles to establish the value and viability of IoT use cases, and present them later to project sponsors. Even for simple IoT use cases, sometimes weeks instead of days may be needed to produce tangible results. In this blog, we’ll present our IoT kick-starter platform that makes it possible to technically assess simple IoT use cases within a few days.
Table of Contents
An IoT kick-starter platform based on native AWS cloud services
To test simple IoT use cases, we use the following technical architecture that enables both a hot path and a warm/cold path to capture and assess sensor data.
To send sensor data to the cloud, we first need a compatible device intended to test the use cases. As illustrated above, it is possible, for example, to simulate sensor data through SDK, the AWS IoT device. The device and the AWS cloud use the AWS IoT core to communicate and forward sensor data to other AWS services. Here, the upper route represents the hot path over the AWS IoT SiteWise, thereby achieving near real-time use cases. Depending on the configuration of S3 services, the lower route of the architecture reflects the warm and/or cold path for executing time-uncritical analyses. AWS Glue allows automated data cataloging, while Amazon Athena serves as the interface for SQL queries.
To test AI or data warehouse workloads in the cloud for an IoT use case, the above solution can simply be extended with cloud services like AWS Redshift or AWS Sagemaker, and easily linked to Amazon Athena.
Enable reusability with the AWS Cloud Development Kit (CDK)
We used CDK to make the AWS IoT kick-starter platform available immediately, and enable iterative adjustments and reusability of the above architecture. CDK makes it feasible to define and configure the cloud infrastructure using code abstraction: once developed, this code can be made available through a repository.
Beyond configuring the cloud services, the data model can define the sensors and machines, which enables them to be monitored via the model. This is done by defining an asset’s measurements or attributes. Measurements refer to physical properties of the asset, which could, for instance, be the temperature or speed. These are recorded regularly from the asset and saved in IoT SiteWise. In contrast, metrics refer to properties derived or computed from measurements. They can be used as aggregate values or statistical for an overview of the asset’s status. For example, a metric could be the average temperature over a given time period computed from the underlying measurements. The excerpt below from the code illustrates one such example.
Do you want to replace the IoT core with a multi-cloud solution and utilise the benefits of other IoT services from Azure or Amazon Web Services? Then get in touch with us and we will support you in the implementation with our expertise and the b.telligent partner network.
Many users of Google's IoT Core are currently looking for a successor to this service which will expire in August 2023. This blog post shows how Stackable's data platform can be used to create a highly scalable open-source alternative to Google's IoT Core.
Many security considerations involving Azure revolve primarily around network security. Other important security aspects to be considered in the context of Microsoft Fabric are indicated below.
How can I integrate data sources that are secured via private endpoints into Fabric? How do I deal with Azure Data Lakes behind a firewall? This blog post shows the possibilities which Fabric Nativ offers