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.
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.
Illustration: Architecture of an IoT Kick-Starter Platform
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.
swise.CfnAssetModel.AssetModelPropertyProperty(
data_type='INTEGER',
logical_id='3',
name='Temperature',
type=swise.CfnAssetModel.PropertyTypeProperty(
type_name='Measurement',
)
),
Illustration: Defining the Measurement
swise.CfnAssetModel.AssetModelPropertyProperty(
data_type='DOUBLE',
logical_id='4',
name='Temperaturemetric',
type=swise.CfnAssetModel.PropertyTypeProperty(
type_name='Metric',
metric=swise.CfnAssetModel.MetricProperty(
expression='max(temperature)',
variables=[swise.CfnAssetModel.ExpressionVariableProperty(
name='temperature',
value=swise.CfnAssetModel.VariableValueProperty(
property_logical_id='3'
)
)],
window=swise.CfnAssetModel.MetricWindowProperty(
tumbling=swise.CfnAssetModel.TumblingWindowProperty(
interval='1m',
)
Illustration: Defining the Metric
Need to execute a proof-of-concept for IoT use cases? Call us – we can assist you immediately with our AWS-based IoT kick-starter platform.