WELLINGTON DURAES: Hello, everyone.
Welcome to Build.
I'm Wellington, with the Azure IoT Device SDK Team.
Today, we're here to talk a little more
about the device builder experience.
I'm going to be covering a bit of the IoT devices,
looking at categories of devices,
then we'll be looking at
the Azure IoT device SDK solutions for device builders,
then we'll be looking at what happens beyond SDKs,
and finally, we'll close by looking at the SDK roadmaps.
Let's start with categories of IoT devices.
When we're working with IoT devices,
one of our initial concerns was to clearly define
the categories of devices to create SDKs for
because we would like
to create the SDKs that are the most
appropriate for the category
of devices that will be used with.
Here, as you can see,
we have a number of devices going all the way
from small 16-bit microcontrollers,
going for a range of different 32-bit ones.
Then we start seeing single board computers in here,
like the Raspberry Pi or the LattePanda here.
Then going all the way up
to Raspberry Pi compute modules or PCs,
and even servers on the rack.
They're all potential IoT devices.
The first way in which we can look
at defining these devices could be,
say, let's look at their architecture.
If we divide like this,
we would have this single pick 24
here as the 16-bit computer, and
then go into all the 32-bits,
and here we have a distinction
between a bunch of
microcontroller-based ones like ESP 32,
ESP ritual 66, some ACM 32,
the Annex B, going also, again,
to do the Raspberry Pi and the LattePandas, and then
going all the way up to the 64-bit computers.
Looking at their architecture could be
a way to categorize these devices.
That's not the only one.
We could also look at this distinction
between microcontrollers or all of
these devices that are based on
microcontrollers going all the way to microprocessors.
Still another way to look at this could be maybe
a category that can run
bare-metal like all of these microcontroller based ones,
or a real time operating system like Azure RTOS,
FreeRTOS, and so many others,
moving all the way to devices that will be
running a full operating system like
Linux or Windows or even Custom
OSs based on, say, Yocto Linux.
But for us here at the device team,
we are pretty much looking at
a categorization that will look at
these two main categories.
The first one will be the sensor class category.
The sensor class is defined by
being based on the microcontrollers.
They will be running
bare-metal or some real time operating system,
Azure RTOS, FreeRTOS as I said,
and they will likely to be running
something like C, C++.
We're seeing more and more Python devices,
microcontroller capable of running
Python, or some assembly.
In the other hand, we have Edge class
devices that will likely to
be running on a microprocessor,
running on a full operating system
or a custom operating system,
and they will be used in
higher level languages, or programming languages.
Then the final picture will be something like this.
Everything from the bit 24,
which is, again, a 16-bit one and before you
ask for about 8-bit microprocessors,
they could potentially run IoT devices.
But for the most of them,
this is too much to ask, so we don't normally
support them or we don't have samples for them,
16- bit is really the minimum bar.
This will all be the sensor class devices and all of
the other ones to the right here will be
the Edge class device.
This is important because our SDKs and your
choices when connecting your devices
to Azure IoT platform,
will likely to be aligned with one or the other.
Let's take a look at what are
the options when thinking about the device SDKs.
Here in this slide, as you can see,
we are aligning our options and
our possibilities for device
SDK based on that definition we just presented.
Under sensor class, we have the C,
both the C and Embedded C SDKs.
We also have the Azure RTOS middleware.
This is a middleware that is also based on
the Embedded C and it was
made to enable Azure RTOS devices
to be connected to Azure.
We did the same with the FreeRTOS which
is also based on the Embedded C,
and it was made to
allow FreeRTOS devices to get connected.
Finally, we have the Arduino Libraries,
which would allow Arduino-based devices
to get connected to Azure,
also based on the Embedded C SDK.
On the Edge class category of devices then we'll
start to see things like the C# or .NET SDK,
we have the Java SDK, we have Python SDK,
and we have the Node.js SDK.
When we're looking at all of these devices,
you might be wondering, but what is this SDK again?
In our definition of SDK, SDK is a set of samples,
documentation, and the client libraries
that will be used on the devices.
That's great. But why do I need a device SDK?
Can I connect my device? Here's a device.
Can I get this device connected to Azure
directly leveraging without using an SDK?
The answer is yes.
All of the APIs for Azure IoT are public,
they have documentation and there's really
nothing preventing you from doing that.
However, when you take advantage of
a device or a client library like this,
you get the advantages of
first, simplifying the connectivity,
meaning that you get an SDK that
would allow you to do that directly
straight without having to worry about what are
the APIs involved or how to call these APIs.
Things like provisioning and
authentication are part of these client libraries.
You get support from Microsoft for all of these SDKs.
Every time there's a new feature,
we're going to be adding these features to the SDKs,
so you get always the latest and greatest from Azure.
There is an important component of
cost savings in terms of; first,
the bill of materials,
when you have the need for less memory,
for less CPU power to run
your devices so that makes it cost less.
Also, because when you are leveraging one of these SDKs,
so there's hundreds of
investment in engineering hours to create
these SDKs that you
taking advantage of the SDK of have to do,
it will save you development money
and also it allows for
a faster development because
these SDKs are provided with samples,
you're provided with documentation
that you can take advantage of,
and it will likely shorten
the time to get your product to market.
But these SDKs they go way
beyond as we can see here in this picture,
we're looking at the client libraries that
they go way beyond that.
As we can see here, these SDKs,
they're not only providing the client's libs,
as we can see here on quote,
the client library with the tests,
or code snippets, and the samples or
examples for all of this code; there is much more.
There's guidance in terms of
the documents showing what to do.
There's documents showing how to do things,
how to do porting,
to porting guidance, and things like that.
There's also supporting material that would help
both getting your device
connected and all of the internals for the device,
but also the external on how to
leverage all of the IoT services from Microsoft.
There are tools in
terms of helping with a code generator,
diagnostic tools, simulator tools as well.
This is all to help you, customers,
help the engagement with the community
engagement with our teams,
also to get connected to our
community via blogs, and video, and things like that.
There are a number of other ways in which we can
get connected to customers leveraging our SDKs.
There's also the fact that when we look at
the future of where these SDKs are going,
one of the things we do a lot is to hear your feedback
and get your feedback
about what's working, what's not working.
Which leads me to this next point,
which is looking at the next generation of our SDKs.
Let's take a closer look at this.
Currently what we have is the Generation 1 SDKs.
They are built to support all MQTT,
AMQP, and HTTPS.
They pretty much bring their own MQTT client.
We call that hardcoded because it's hard
to change that for another
client library if you don't like the one we have.
Same goes for networking,
and because we are bringing all of these capabilities to
us to have all support for all MQTT,
AMQP, and HTTPS, changing them might be complicated.
Also, they tend,
because we have all of these internal layers,
getting error codes might be a little cumbersome.
Finally, the feature set is
not consistent across all of the different languages.
Now, when we look here at
what's going to be with the Generation 2,
that's a completely different approach
in which here, you can see we're going to be
focusing on MQTT as
this standard approach to get devices connected.
Bring your own MQTT client for lift and shift scenarios,
not only for that but also for
the networking for embedded systems.
You get here a bring your own network stack,
MQTT, TLS, and socket.
These are all choices
customers will have with Generation 2.
They are flexible and layered.
They will surface all of these IoT hub error codes for
easy to use and reconnect and
to treat these errors if that's the case.
Finally, these SDKs would be functional equivalent,
but they were still maintaining their language style,
which mean that even though across
the SDKs the functionalities will be there,
we're still understanding and respecting
the fact that when you create something in C,
it should look and behave like a C application, and
same goes for C#, and same goes to Java.
This is not only the plan for the future,
but this is already a reality for some of the SDKs.
When we're looking at what are
the SDKs of Generation 1 that are alive,
so these are all of the options C,
Java, .NET, Node, and Python.
When we look at what is
next generation or Generation 2 of the SDKs,
actually we already have a set of
SDKs that are in this Generation 2 already.
We have the embedded C SDKs,
the Azure Atlas Middleware, we have the FreeRTOS
Middleware, and the Arduino Libraries.
All of them already have
these benefits that I was talking about,
specifically about the bring your own network stack.
We are in the design phase to bring
not only the C-based SDKs but
all of the other SDKs also to Generation 2.
Right now they are in design phase.
We don't have a date for this yet,
but this is where the Azure device SDKs are headed for.
Finally, let's take a look
at the device SDKs feature roadmap.
Here we have a bunch of things
that we are doing for all of the different SDKs.
As you can see here,
we start by looking at the built in
PnP or plug and play support for the .NET SDK,
which is already being released as per February.
Same goes for the Java SDK
with the Version 2 there's a major release.
This has been released as per last week and coming on,
same a long-term support release for Python.
This is also for April and
then for the Arduino Libraries,
we are bringing samples for additional dev kits.
Right now we have samples for Arduino-based devices,
but we don't have any for an Arduino official board.
We will be doing that soon, bring in a couple of
official Arduino boards.
Then, on May,
we should be bringing cellular samples,
so samples showing how to get
FreeRTOS-based devices connected to
Azure using cellular connectivity.
Then comes June, we're going to be building the
public preview DPS x.509 cert
management tools for both the Python and .NET SDKs.
Then July 2022, also in public preview,
we should have the over-the-air capabilities leveraging
Azure Device Update for both
embedded C and FreeRTOS Middleware,
which means that small devices will be able to have
this over-the-air update capability
natively from the SDKs.
Then finally, looking at July 2022,
we should have a long-term support release
for the C SDK and also
the Native PnP API support as well.
As you can see, there's a lot we're doing,
there's a lot more to come on the Azure IoT Device SDKs.
As I said before, we have this distinction between
small constrained devices and we have
this whole set of bigger devices.
We are creating SDKs that would help you get
your device connected to
Azure regardless of its architecture,
its size, memory capacity, and things like that.
We have a roadmap packed with
features that will help you get your devices connected.
Let's take a look at our SDKs.
If you have questions, if you have comments,
we're always happy to engage with you.
If you find anything that's not working well for you,
please log an issue in our GitHub repositories.
Please also keep in mind that all of
the SDKs and everything we showed you here,
is open source and free to use, free to modify,
free to adjust to
whatever specific need you have for your devices.
Take a look at those. Take a look at our SDKs,
see how much they can improve your development cycle.
How can they help you accelerate
the development of your solutions
to get connected to Azure IoT.
As always, if you have any comments,
questions, please get in touch.
That's it for now. Take care.