- Hi, my name is Ali Benfattoum.
I'm a Principal Evangelist in the AWS IoT team,
and I'm back in school today to show you
how you can easily build a digital twin of a classroom
using the Smart Territory Framework
and AWS IoT TwinMaker.
Cities, like the city of Drancy from where I stand today,
use AWS services to build innovative solutions
to monitor air quality in schools.
They can make sure they provide
a safe learning environment for the children.
They can also improve the efficiency of their buildings,
and detect any anomaly, like a window left open
during the night, or the weekend.
So in this video, I'll go through all the steps
to build this kind of solution
using indoor environment monitoring LoRaWAN sensors
from three different vendors.
I'm going to leverage the Smart Territory Framework
to ingest and store standardized data.
Then I'll show you how you can use AWS IoT TwinMaker
to build a digital twin of a classroom.
You can find more information in the video description
about the Smart Territory Framework,
the AWS services, and the devices used in this solution.
So let's get going, and start with a simplified view
of the solution architecture.
There are six components in this solution.
We'll start first by deploying the core of the STF,
STF being the acronym of the Smart Territory Framework.
The STF is open source and built on open standards.
It enables decoupling data producers from data consumers,
making it easier to build scalable, sustainable,
and interoperable solutions.
Once we have our foundation set,
we will connect our sensors, and build data producers.
All the data ingested from these data producers
will be stored in a standardized format
in the STF IoT data lake.
So we will use Amazon Athena to query this data lake,
then AWS IoT TwinMaker to build a digital twin
of our classroom, and Grafana to visualize the twin
and the environmental data.
And finally, I'll show you how you can build
an alerting system to be notified
when specific conditions you define are met,
like for example, the temperature going below
a certain threshold.
For the first four steps,
we will use AWS Cloud Development Kit,
CDK for its acronym.
AWS CDK is an open source software development framework
to define your cloud application resources
using familiar programming languages.
The links to the CDK stacks that we will use
are in the video description.
That being said, let's start with the first step.
In this step, we will deploy the STF Core.
The STF Core consists of two modules,
the open source FIWARE Context Broker
and the STF IoT module.
With the STF Core, you can assemble
and store information from different systems
eventually belonging to different organizations,
instead of having them perform in separate silos.
It provides a central and unified registry
for all your devices and sensors,
regardless the operating model, the technology,
and the connectivity used.
It offers digital twin capabilities,
enabling you to store and retrieve in real-time
the current state of every registered device.
It also consists of an IoT data lake built on Amazon S3
that you can use to store query
and generate insights from your IoT data.
Once the core is deployed,
it's easy to integrate data producers,
whether they are sensors, new applications,
or legacy systems, and same for data consumers.
The STF Core offers multiple ways to consume the data
directly from the context broker
from the STF IoT registry, or from the STF IoT data lake.
You can also subscribe to all changes in your data,
making it easy to build real-time applications.
Finally, you can create subscriptions
to notify independent systems and applications.
You can combine all these capabilities
to build comprehensive and scalable solutions easily.
You can iterate and innovate at a fast pace.
So let's deploy the STF Core stack.
We'll visit the STF Core repository on GitHub,
and we clone it.
With CDK, you can deploy the STF Core
with only three lines of commands.
npm install to install the libraries,
cdk bootstrap to bootstrap your AWS environment.
You only need to bootstrap your environment once.
And finally, cdk deploy to deploy the stack.
And that's it.
Half an hour later, the STF Core is deployed,
and we can see in the outputs of the stack
the two information we need to interact with the STF Core.
First, the StfCoreEndpoint,
which is the unified API to interact
with both the context broker and the STF IoT module,
and the ID for the STF IoT queue.
This is the entry point for all data producers
to publish data.
This information is also available
in the CloudFormation console.
We can move to the second step,
and connect all data producers to the core.
In this solution,
we use three LoRaWAN indoor environment sensors,
the SenseCAP S2103 from Seeed,
which can also be used outdoor,
the AM103 from Milesight,
and the ERS Sound from ELSYS,
and we use a gateway from RAKwireless
connected to AWS IoT Core for LoRaWAN
to ingest data from these sensors.
For each type of device,
we will have a dedicated data producer,
including a Lambda function that transforms
the binary payload received from the sensor
to a standardized format using
the NGSI-LD compliant Smart Data Models.
NGSI-LD is a specification that provides an open API
for managing and requesting information
and an underlying information model
based on entities that are digital representations
of real-world objects,
having properties and relationships with other entities.
Every information stored in the STF is an NGSI-LD entity.
The STF leverages the NGSI-LD compliant
Smart Data Models Initiative that provides
open licensed data models for different domains,
such as smart cities, smart building,
and smart manufacturing.
Each device registered in the STF IoT registry
is described using the Smart Data Model named Device.
For the measurements of our sensors,
we will use the data model IndoorEnvironmentObserved.
More information about the Smart Data Models
and the NGSI-LD specification in the video description.
We provide in a GitHub repository the code of a stack
to deploy an STF data producer using
AWS IoT Core for LoRaWAN.
We include samples for multiple type of sensors,
including the ones we use in this solution.
So let's clone it.
Again, we install the libraries
with the command npm install.
We select the type of sensors we want to deploy a stack for.
No need this time to bootstrap our environment
as we did it before.
So we can directly deploy the stacks.
Three stacks will be deployed,
one for each type of sensor.
Each stack includes a LoRaWAN destination
to route the LoRaWAN binary payload received
to a dedicated Lambda function via an IoT route.
We can check one of the Lambda functions.
We can see in the Lambda function
that the payload is first transformed into an NGSI-LD entity
using the IndoorEnvironmentObserved data model,
and then published into the STF IoT queue.
We can also check that a LoRaWAN destination
had been created for each type of sensor.
All good.
Now, we can onboard all sensors,
selecting for each of them the right LoRaWAN destination.
But first, we need to create a device,
and a service profile for all devices.
Done, we can now register the LoRaWAN devices,
providing the different keys needed.
We do it for each sensor.
We are using the console for this video,
but obviously, you can use the service API to do it at scale
for a larger number of devices.
We quickly register a LoRaWAN gateway
to AWS IoT Core for LoRaWAN.
You can find in the video description
a link to a video that explains how to register devices
and gateways to AWS IoT Core for LoRaWAN.
We check that the gateway is connected.
All good, we can now receive data from the sensors.
The last step to link the data producer to the STF Core
is to register the devices in the STF IoT registry
We use the STF unified API to register the devices
providing all the attributes
as defined in the data model Device.
We can then check in the IoT Core registry
that the thing is created,
and that it has an entity of type Device attached.
In the meantime, we received data from the sensors.
So we can see that there is another entity of type
IndoorEnvironmentObserved that is attached to the thing.
It contains the environmental data.
Using the STF API, we can get the list
of all the things registered
with their associated entities of type Device.
We can also get all the entities associated to a thing.
In that case, we have two entities associated,
one of type Device describing the device itself,
and one of type IndoorEnvironmentObserved
with the measurement.
The entities published into the STF IoT are sent
to the context broker,
and also stored in the STF IoT data lake.
Entities stored in the STF IoT data lake are partitioned
by type and time.
This makes it easier to run high-performance,
cost-efficient analytics on data
using various services, such as Amazon Athena,
which is what we are going to use in the next step.
Indeed, in this step, we are going to use Amazon Athena.
Athena is an interactive query service
that makes it easy to analyze data directly in S3
using standard SQL.
Athena is serverless, so there is no infrastructure
to set up, or manage,
and you pay only for the queries you run.
We will create multiple resources in Athena.
First, a workgroup named STF,
dedicated to all our STF-related workloads,
then a database.
A database in Athena is a logical grouping
for tables you create in it,
and finally, a table.
A table in Athena contains the metadata definitions
of a schema for the underlying source data.
In our case, the source data will be the STF IoT data lake.
The metadata in the table tells Athena
where the data is located in S3,
and specifies the structure of the data.
So for this solution, we'll create a table
for the data model IndoorEnvironmentObserved.
We provide a GitHub repository for this step
in which you can find a CDK application
that will provision these resources.
We use the same commands to deploy the stacks.
You can see that we provide the schema
of the data model IndoorEnvironmentObserved
for the creation of the Athena table.
After a few minutes, we can check in the Athena console
that the workgroup, the database, and the table are created.
We can start querying the data.
We start with a first query just to preview the table,
and a second query this time to query the measurements
from the sensors.
You can now easily plug any API, or visualization tool,
like Grafana, or Amazon QuickSight, to visualize the data
and extract insights.
Here, an example, using Amazon QuickSight
to visualize on a map the location of the sensors,
the measurements of CO2, temperature,
and humidity over time.
This dashboard directly queries the Athena table we created
to get the data.
Now, let's go further,
and create a digital twin of the classroom.
We'll use AWS IoT TwinMaker to build
the digital twin of the classroom.
With TwinMaker, you can use existing data
from multiple sources, create virtual representations
of any physical environment,
and combine existing 3D models with real-world data.
In this step, we also use a GitHub repository
available in aws-samples
that is named aws-stf-dc-twinmaker.
This repository provides an example
of how to build a digital twin using TwinMaker
in combination with Athena to query the data
from an S3 bucket.
It contains a CDK application
that will provision multiple resources in TwinMaker,
including a workspace, which is a top-level container
for all digital twin application,
a component, which will connect all data source
to the twin application,
and one, or multiple entities,
which are digital representations
of the elements in all twin.
The STF also uses the concept of entity
to store information, so we can easily link STF entities
and TwinMaker entities together.
We specify the names of the things
we want to create entities for in TwinMaker,
and then we deploy.
After a few minutes, we see in the TwinMaker console
that we have a workspace, a component,
and three entities created.
The component we created is attached to our entities,
so we can start fetching the data
from the STF IoT data lake for these entities.
We test the component to see if we get the data as expected.
All good.
We see all the measurements for the time range
and the entity selected.
We can now create a scene.
A scene is a 3D visualization of the twin.
When we created the workspace,
we created in the meantime an S3 bucket
in which we can upload all the resources
to create these visualization.
We use a simple model of a classroom in this video,
but you could, for example, use tools and solutions,
like the ones from Matterport, to transform your space
into a realistic 3D model.
Once the model is uploaded, we can set up the scene.
We create tags.
Tags are annotations added to specific coordinates
used to connect a scene path to entities
and their properties.
So we create a tag for each property
we want to attach to the scene.
We select then the related property in the entity.
Also, we create rules to provide a visual indicator
based on conditions we specify.
For example, we can change the icon of the tag when the CO2,
or the temperature is above a certain threshold.
We have everything set up now
to create a dashboard to visualize our twin.
For this step, I will just show you an example
of a Grafana dashboard I built when preparing this video,
but you will find in video description a link
to the documentation describing how to set up
a Grafana dashboard yourself.
AWS IoT TwinMaker supports Grafana integration
through an application plugin,
so you can visualize the scene,
and query the data through the TwinMaker API.
We only used one type of data for this solution,
but you could build twins aggregating data
of multiple types and from multiple sources.
You could, for example, integrate the weather,
the air quality outside the building,
and its energy consumption to have a holistic view,
and then control the HVAC system to improve the comfort
and the efficiency of the building.
So in the last step, I'll show you how you can use
the STF Core to easily notify an independent system
based on specific condition you defined.
We will create a subscription in the context broker
to receive all measurements
with a temperature above 22 degrees.
Before we create this subscription,
we'll first create an independent system.
We keep it simple and just create a Lambda function
that will log the data received.
We then create an Amazon API Gateway endpoint
to trigger that function.
When creating the subscription, we'll provide this endpoint.
We have everything we need now to create the subscription.
So we use the STF Core endpoint to create a subscription
in the context broker.
We specify the type of entities we want to subscribe to,
the specific condition to trigger the notification,
in our case, it's when the temperature is
above 22 degrees Celsius,
and then we provide the endpoint that we created,
and that's it.
We create the subscription,
and we can check that the subscription is created
in the context broker.
Now, at the moment, the context broker receives an entity
of type IndoorEnvironmentObserved
with the value of the property temperature above 22,
our system will receive a notification with this entity.
And voila, the system we created have received
a notification with an entity
of type IndoorEnvironmentObserved
with a temperature measured of 27.62.
We could then trigger specific actions,
interact with an HVAC system, as mentioned before.
Using subscriptions is also a way to decouple systems.
You can create subscriptions to share
with independent systems the data they need
without them having to fetch the data.
Well, that's it for this video.
We've seen how you can use the Smart Territory Framework
and AWS IoT TwinMaker to build a digital twin
with the example of a classroom.
We covered how to deploy the STF Core
and multiple data producers using AWS IoT Core for LoRaWAN,
how to use Amazon Athena to query the data in the data lake,
then how to use AWS IoT TwinMaker
and Grafana to build and visualize your twin.
And finally, we've seen how you can use subscriptions
to connect and interact
with independent systems and applications.
You can find in the video description more information
about the STF and the AWS services we used,
and it only remains for me to thank you for watching.
I hope you found it useful,
and that it will help you build
your own digital twin applications.