>> When integrating IoT solutions,
that's not the way easy.
There's lots of technologies going on,
you need to understand your domain,
you need to understand the Cloud, and so forth.
That's why you need to have support from an integrator like AMIS,
specialized in smart grid solutions.
Tomasz and Robbrecht are here to
share their insights, their learnings,
the pitfalls of integrating IoT solution,
and how they do that in their company.
That's today on the IoT Show.
[MUSIC]
>> Hi, everyone. This is the IoT Show.
I'm Olivier your host.
Today we'll talk about a return on
experience building smart grid solutions,
some tips, and tricks from experts.
For that, we have Tomasz and Robbrecht from
AMIS who are a partner of Microsoft.
Tomasz, Robbrecht, thanks for joining the show today.
Let's do some introductions to get started.
Robbrecht, what about you?
Who are you? What are you doing in life?
>> I'm working as the Head of IoT with
AMIS Conclusion, and we're working on scaling up
IoT solutions for energy manufacturing companies in
the Netherlands using Microsoft technology, and
especially last time in the energy, and smart grid solutions.
>> Nice. How about you Tomasz,
a little introduction about yourself?
>> Hello, I'm Tomasz Brzezinski.
I'm a principal solution architect at AMIS Conclusion.
I'm the IoT solution architect
of the platform that we are going to talk about today.
>> Nice. I very much appreciate your time.
As you were saying, you're calling from the Netherlands,
so very much time difference here,
so I think it's late in the evening for you.
We appreciate your time here,
and also your presence because it's super important to
discuss the importance of integration in IoT.
IoT solutions are becoming bigger and bigger.
They are also complex to integrate, and having
experts like yourselves help our customers,
or join customers getting to
produce my solutions that will have their own customer.
What's specific about smart grid solutions
compared to IoT Solutions in general?
Are there several things you can
share with us that make smart grid solutions
particular, and your expertise in
that domain even more required from our customers?
>> I can elaborate a little bit about this.
Compared to regular smart grid solutions,
regular IoT solutions,
smart grids, it's very
large in scale, and it's the first difference.
Another one is scale number of devices,
but also the frequency
of the messages which are being sent around.
I think that the second one is the complexity in messaging.
That's the back and forward.
First, you need to measure the state of the smart grid,
and if you come to the conclusion that something is wrong,
that's just something they have
to send messages back to adjust the settings in
this network, or just to adjust settings and physical equipment.
Because it's physical equipment,
security is also very important because
that's more generic for every IoT solution.
>> Yeah. When you're talking about scaling,
it's not just about the number of devices,
it's also about the variety of the devices,
very different types of devices from different manufacturers
installed, and deployed by
different vendors or different contractors, I guess?
>> That is correct. A couple of years ago,
we just saw specific siloed solutions for
a specific type of meter, or a specific type of valve,
or a specific type of electrical engine.
Our companies are more and more trying to
integrate this into a whole grid solution.
That means that you have to process data from very small,
quite simple smart meters all the way down
to very complex and big complete energy systems,
for example, and connect them to each other and
also integrate them into the backend systems,
which are also, in this case, enterprise-grade.
It's like we are the plumbers of data processing in this area.
We take data from a very specific place,
get it to a central place where decisions are being
made from enterprises, and for analytics purposes,
and send data back to
a very fine-grained network which is already in place.
>> Nice. Just to give us an idea here,
we're talking about actual real smart resolution deployed,
we'll not say the name of the customer,
but how many devices,
how many endpoints are we talking about here?
>> Now, initially
these companies thought that
they already had the smart grid because
every energy companies need some information about measurements,
how much energy or power is being used.
That initially started with 300 devices as
a minimum viable product, but we got involved in this project just
to scale this up to a larger number, and also to
a larger number of types of products.
At the moment, we are at about 15,000 connected devices and
it's still growing with about 100 devices a day.
It's scaled for a couple of 10 hundreds of thousands of devices.
As for the frequency of the measurements in general,
you could expect that when you talk
about energy meter for billing,
that will be sufficient to measure once a day or once a week.
In this case, we're measuring
every 50 minutes, and it's being ramped up to,
at the moment for some devices,
almost every two minutes.
>> Well, interestingly for people
who are not familiar with IoT scenarios might be like,
Oh, why do I have real-time data coming up?
But yeah, when you talk about scale and number of devices,
then once every two minutes is actually
a lot because it's coming from all these devices,
that it's something that
maybe you have to have in the backend that can support that.
We like to think that Azure IoT is
a set of services that allows scaling flexibly.
I would like for you guys eventually, Tomasz,
to tell me a bit more about the architecture, and how you're
using the various services that we're offering
and maybe point at the places where the scaling is made
easier in terms of
implementation of your size thanks to these services.
>> Yeah, actually, this solution gave us the opportunity to use
various products, and various services offered by Azure Microsoft.
If we could show the slides,
there is an example of some of the services that we are using.
We are using IoT Edge,
we are using IoT Hub with device provisioning system,
we are using event grid to trigger
several different types of functions,
we are using stream analytics,
Cosmos DB, all the services that you could see.
Probably you could recognize
some of the patterns that are advised by Microsoft.
That's another thing which helps us a lot.
Quite good documentation, and
good reusable patterns that
we can compose in quite complex solutions.
>> Nice. You just mentioned that when you
start with IoT solution development and implementation,
it's not always easy to identify what's the right setup,
what's the right configuration,
what's the right architecture here.
We have these guidances,
these reference design, or architecture that we provide,
but I personally think that having
the expertise of someone like you guys who have been through,
for a specific area or domain
implemented your own architecture on top
of the recommended, or suggested ones
is definitely the way to go because it's not simple.
But actually, if you could share with us some of your insights,
as you have been working with these servers for a long time,
as you are an expert at the company and as
individuals who are experts in the domain
of smart grid in particular,
but what are the things that you would say
are the best practices, the key learnings,
the pitfalls that you identified
while you were working at aggregating these services in
the Cloud and that you can share so that everyone
actually knows what they're
going to be facing when you start aggregating solution?
>> That's the scalability of
the solution is probably the main thing.
We have started,
as Robbrecht mentioned,
preparing proof of concept
that was already designed to be scalable.
However, with the growing amount
of different types of
devices producing data with different frequency,
we found out that some of the solutions
that we adopted were not suitable for it.
For example, when we created the solution,
we used Influx as a database for a time series,
and then throughout the project,
we discovered that there is
a new service from Microsoft Azure Data Explorer,
which simply perfectly fit our purpose.
Then we adopted that service and instead of Influx,
that's one of the examples.
>> Nice. That's basically trying to keep up
with the rhythm at which Microsoft is releasing products.
Not saying that you should always switch to the latest,
or greatest, or whatever we release at Microsoft.
But as you were saying, you identified that as
better fit for your architecture, and for that solution,
and we're able to adopt that.
I think it's actually another argument for our customers to go
to integrators and partners like AMIS because that way,
they don't have to keep track of all of
that or try and keep the pace.
You are experts, you see them coming, you evaluate them,
these new services and features, and then you can
propose your customers to deploy that in their own solutions.
>> That's correct, and then sometimes keeping up with changes and
new services offered by Microsoft Azure
is quite complex for someone who is not really deeply technical.
Then another example is the rank or projects.
Microsoft also released the Kafka extension for Azure functions.
That's another thing that greatly
facilitated our integration work.
If you could say go again to the slide please,
then you could see we are using Kafka to
integrate with external systems of our customer,
and then we process quite a lot
of data in both ways so we
subscribe to topics to consume the data,
but we also publish some data that is
consumed by external systems.
That's, you could say,
it's central part of connecting with all other systems.
Therefore, the extension for
Azure functions greatly help us to simplify the solution.
>> Nice.
>> I think it's just to elaborate a bit more
about this concert and is our stricter.
When we started, some of
the business guys were already very clear,
but there were a lot of business guys which
were still in development so we needed a platform
where it was very easy to add a lot of
new functionality without all the groundwork
of setting up databases,
or application services, or integration components.
This made it possible to be very
flexible in the functionality, and in the logic,
and the integrations we were creating without completely
refactoring our structure from
scratch when something new was happening.
For example, in the beginning
the requirement was to send
out there for half an hour or 50 minutes
a message, and now we're talking
about every two minutes and probably can happen
that in the near future we would like
to have a message and
also a message back within a couple of seconds.
Is our architecture prepared for this it will probably
use some different components and some different logic,
but you can change it while you're working on it.
You don't have to redo a lot of things again.
Also the openness of the architecture make this possible that
this isn't completely open architecture on the back end.
Some of the logic is not in our Azure technologies,
in different systems because they are
specialized in optimizing the energy grid,
talking to other systems,
to energy providers, to consumers.
They're not included in Azure,
but we can communicate with these in a very secure and open way.
>> I see. There's actually two main ideas here that you shared.
One is being try and reduce,
I would say the amount of custom could
by using existing components,
existing services and the second one is the capability of
integrating with third party or the other solutions in one place
and that is secure in terms of establishing communications as well
as communicating data transfers and hosting.
>> Also, as Robbrecht recommendations to
modularity of the solution help us to either
substitute a certain service or
upgrade it or add additional functionality
or additional services without the disturbing
the entire platform without isturbing the existing data flows.
>> I like the way you Robbrecht discussed about
the fact that you're the plumbers for
smart great solutions and I do like that because I do like to say
myself that Azure IT or
IoT in general as a technology is plumbing.
As plumber, it's natural to use
the services or package and you just aggregate them
into a solution and you adapt that solution based on
your understanding of how the flow of data needs to go,
the requirements in terms of scaling,
in terms of security and so
on so I like this idea where the plumbing you're
the plumbers that works really well for our joint own customers,
and at the end of the day aggregating
IoT or putting together IoT solutions is not easy.
It's not simple. Lots of moving parts as you were saying,
technology is evolving super fast and
so being able to count on skilled people would
know their part and understand how to integrate them
into a better solutions or application, I think is key.
That's one of the learnings on your side.
>> I think you're absolutely
right about having skilled people, of course,
but also to have the knowledge to look a little bit ahead what's
happening next because you can build
something which is working right now,
but it also has to work in a couple of years or in 10 years.
These systems are working
with those things which are connected in the real world
and when something locally isn't working you
have to visit the driver of that connectivity,
it's far too costly when you talk about 10,000
of devices so you have to think
upfront about creating something which is quite
stable in the edges,
but also very flexible internally
so to adjust it for functionality,
to adjust it for new features and to readjusted
for connecting to different systems in the backend.
>> Nice. Well,
Thomas, Robbrecht, I think to a good insights.
Thanks for sharing your learnings,
the best practices in creating
IoT solutions in the context of your smart energy grid,
which is really nice.
We have a link. We're going to bring up
down there aka.ms/iotshow/AMIS,
which is the name of your company.
If people want to reach out,
do they just like reach out of running
contact info on AMIS or how does it work.
>> When you go to this link, you can find
my contact information or Thomas contact
information and feel free to drop us an e-mail
when you want to know more about the solution.
When you want to know more about
the technology or the business benefits,
or where you want to
enjoy working with our colleagues
and everything is possible with us.
>> Great. Well,
thanks for your presence today and for sharing all these insights.
I'm sure people will appreciate and realize that they can work
with integrators like AMIS to get their solutions out there.
Thanks for your time,
and thanks again for joining us
today on the IoT show. See you soon. Bye.
[MUSIC].