Hello everyone. My name is Mikhail Zaytsev.
I am a System Engineer at Orion Innovation,
formerly MERA company. MERA is a Linux foundation
and AGL member since January 2020. Since the
time we have joined two AGL expert groups,
related to Cloud and virtualization. In this
group of virtualization experts, we have
already upstreamed the support for Xen Hypervisor.
In the scope of the
Vehicle to Cloud expert group we're working
on a new AGL service provider to provide a
Cloud connectivity to different Cloud platforms.
Consider AGL - a software stack for the connected
car - it's hard to imagine that it still lacking
a Cloud connectivity function. So today we
will talk about a new AGL service and I will
also demo how to enable and see scenarios
in AGL using the service.
Here’s the agenda. Let's go through possible
V2C scenarios first, then consider Cloud-connected
concepts to achieve a Cloud connectivity, then dive
little deeper into a AGL Cloud proxy service
solution and finally end with two demos
of the prototype to V2C use cases.
There are a number of V2C scenarios that can
be enabled by connecting AGL vehicles to the
Cloud. Among them are GPS tracking, data logging,
remote diagnostics, remote control and OTA
updates. All these scenarios can be enabled
independently or considered as parts of a
single Fleet Management solution.
Currently such scenarios can be implemented
by using automatic devices. But instead of
using such devices and Cloud connectivity
function, can be integrated inside AGL stack
that will provide a best ability to create
different AGL applications implementing the
mentioned V2C scenarios.
Having a Cloud connectivity in place there
is a need to consider how to exchange a vehicle
data between a weight and the Cloud. The first
approach is to push a record data to the Cloud
without any request from the Cloud. In this
case the amount of data may be exhausted to
meet a particular V2C scenario. The second
approach is to pull the vehicle data from
the Cloud and to precise the amount of data
requested.
Now the presentation will focus on the first approach
– push data to the Cloud. Cloud connectivity
is supposed to be achieved by a set of connectors
to different Cloud platforms such as Microsoft,
Azure, AWS, Google Cloud, Push 80 Cloud and
others. Each connector acting as a proxy between
an AGL ecosystem on one side and the Cloud
platform on the other side. Let the vehicle
data be transferred to the Cloud services
through the Cloud hub. Once appeared in the
Cloud that data can be stored, analyzed, modified,
transformed depending on the intended scenario.
Now let's look deeper into the architecture
of the new AGL service, its internals and
the interfaces towards it.
As you can see all the available connectors
are assumed to be inside a single AGL service
that is acting as an entry point to different
Cloud platforms. The service architecture
is extensible and provides an option to add
the support for a new Cloud platform once
it is needed. The service is responsible for
initialization and connection establishment
to the Cloud Hub, while the AGL application using
this service remains unaware of Cloud specifics.
The communication Channel between the Cloud
hub and the AGL service is established over
MQTT protocol and secured by SSL.
Service provides a bi-directional Communication
channel between a Cloud and AGL application.
That means that the AGL application may receive
any common messages from the Cloud as well
as sent out data to the Cloud. In order to
receive any common messages from the Cloud,
the AGL application shall subscribe on this
option of this service. Another mandatory
condition is that each incoming message shall
contain an ID of the corresponding AGL application
it is destined to, otherwise the service will
not be able to correctly distribute an incoming
data flow among AGL applications using it.
Multiple AGL applications communicating with
the same Cloud platform share the same connection
to the Cloud Hub. So the service doesn't create
a new connection for a new application. The
message payload can be of any arbitrary string
format for example, JSON.
If you look deeper into AGL Service internals,
for instance, at this simplified Class diagram,
we can understand that in order to add the
support for a new Cloud platform, it is needed
to inherit from the defined Cloud client interface.
Once you do that don’t forget about configuration
options to initialize your client and connection
to the hub. For example, it may be a connection
string like in case with Azure Cloud or have
a path to a set of certificates, like in case
with AWS Cloud.
Once we talked about service internals, let's
look in detail how to communicate with this
service.
There are two options, how to do that.
The first option is to use so called AGL application
framework API that is based on a defined set
of verbs supported by the service. I can say
that AGL framework API is cumbersome but it’s
not that straightforward. For that reason,
we developed a special REP API that
consists of just one Cloud Proxy Client class
to simplify the communication with the AGL
service.
On the right side of the screen you can see
a code string of illustrating how to use this
Cloud Proxy Client API used to initiate to and create,
in the instance of this class, initialize it properly, then you can subscribe on the
required events, and finally you can send
a message to the Cloud you want to communicate
with. In this case this is Azure. JSON is
used as a message payload format to transfer
the data to the Cloud.
So, we have talked about the new AGL service
architecture internals and interfaces towards
it and its time to look into that Prototype
V2C Solutions. And the first one is GPS tracking
solution.
The solution architecture is quite straightforward.
AGL application sends the simulated GPS data
to the Cloud where the date is stored in a
time-series database. In our case this is
Influx DB. After that, the data can be retrieved
from the Cloud by Grafana dashboard with a
special plug-in installed to visualize a GPS
tracker. The communication between AGL application
and the Cloud goes through the IoT hub and
the common data is processed by the services
function.
This is the sequence diagram illustrating
the data flow related to this Prototype solution.
Now, let's look how it is working. Cross your
fingers!
So I'm opening a Grafana dashboard with a
special track back plug-in installed. I have
already run AGL virtual machine, and here
a special Cloud Telemetry application created
for this demo. Once I press the start button,
AGL application will start standing simulated
GPS data to the Cloud.
The data will be retrieved by a Grafana dashboard
and that will build a GPS track. As I mentioned,
oh sorry. I didn't mention that but in addition
to the GPS tracking function, there is an
option to control if a vehicle location is
outside or inside a defined area.
So, once the vehicle location leaves or enters
the defined area an appropriate message is
sent from the Cloud to the AGL application
that displays on the screen that will be here
on the string Cloud message.
So, let's see. I press start button. The data
the GPS data is sent to the Cloud and retrieved
by the Grafana dashboard and GPS track is
continuously being built. It is marked in
blue. The defined area is drawn in red, this
is a red rectangle. So once we enter the defined
area an appropriate notification is sent back.
Let’s see how it will be. Just a second.
Yep, we are in the defined area and begin
bounce message is received by the
AGL application.
Let's see what will happen if we leave the
defined area.
We need to wait some time. This is the first
time when this route is built.
It is possible to set only 5 seconds  on the Grafana dashboard.
So while we leave the defined area, we get
out of bounds message from the Cloud. There
is a small mismatch between the message from
the Cloud and the location visualized by the
Grafana dashboard. But as I said, it is due
to the difference between the Refresh interval
in Grafana dashboard and the time interval
that is used to send that data to the Cloud.
I think that's enough. I’ll stop the application.
And I stop sending GPS data to the Cloud.
Let's return back to our Presentation. The
second prototype solution that I want to show
you is called Software OTA update.
Its architecture is very similar to the previous
one. AGL application sends the request for
the updates on the update server. We used
a Hawkbit update server in our case. If any
updates are indicated and available, it downloads
it from the server and installs in AGL system.
The communication between AGL application
and Hawkbit server is going through IoT Hub
and Serverless function where Serverless function
is responsible for translating the request
from the AGL application to the Rest API calls
to the Hawkbit server.
Here in the sequence diagram illustrating
all the three phases of the communication
between AGL application and Hawkbit server.
So the first phase is called Check updates.
AGL application sends Check Updates request
that is forwarded by IoT hub and translated
by Serverless function to the Hawkbit server.
If any updates or no updates available, AGL
application gets aware that by the response
from the Hawkbit server that is forwarded
back to it from the Cloud. If any updates
are available AGL application sends Download
Updates request that is translated to the
particular responding Hawkbit server rest
calls and the Serverless function on behalf
of the AGL application downloads the updates
and send us back by chunks to the AGL application.
Once all the updates are successfully received
by the AGL application, it stores in the system
and send the confirmation that the updates
have been successfully applied. Receiving
this confirmation Hawkbit server marks the
deployment as finished.
Hawkbit Management UI is used for provisioning
devices and deployment base. Now, let's see
how it is working.
We're returning back to our AGL virtual machine
and I'm launching another special demo AGL
application that is OTA Update solution (16:36).
Also I open a Command line console and now
I go to the Hawkbit Management UI.
Here's the device that is used to communicate
with the Hawkbit server. Here is a dummy distribution
set containing a single package called a dummy
app that we're going to download and install
in AGL system using our special software OTA
Update AGL application. I need to
assign this dummy distribution set to this
device. The assignment is
done successfully and you see a new distribution
task running in this list. Then I can go into
the AGL application.
But let's first talk check that there is no
dummy app already installed in the system.
Well, we checked that.
Then we can press the Check Updates button
and see how things are going.
So you see that the AGL application checked
for their updates on the server, received
the response from the server. And it looks
it should be that some updates are available.
It downloaded it. That was a single dummy
app package like it should be, it installed
it in the system. Installation was successful
and then replied back with their confirmation
to the server so that the server marked this
deployment as finished.
If we check in the console log, if there is
any dummy app installed, we see that dummy
app version 1.0 is installed. That is how
it should be. Then let's go back to their
Hawkbit Management UI and create one new dummy
set distribution set.
Version 2.0
Let’s assign a new version of dummy package
to the distribution set.
Done correctly.
And let's go to the deployment top and assign
new distribution set to the device.
Sometimes it takes time. I don't know.
The Hawkbit Management UI is very sensitive.
So we again see new distribution task running
and not finished.
If we check for updates once again, we should
receive the information that new version of
that package is available for downloading.
We will download it and install it, removing
the previous version of from the system. Let's
see.
So as I mentioned, it was checked that application
from the package is not running the previous
version of the package wasn't installed successfully
and then new version was installed. As in
our previous case, it was confirmed to the
update server that the installation passed
successfully. So we can check it in the console.
Here we go. The new version 2.0 is installed
in AGL system. And that is according to our
expectations.
Let's get back to the presentation.
Oh, we are the end – Summary slide. So what
do we have in a nutshell?
A new AGL service providing Cloud connectivity
and abstracting AGL applications from Cloud
specifics.
It is planned to Upstream this service in
the upcoming AGL Jumping Jellyfish release.
Currently only the support for Azure and AWS
implemented. However, it is possible to extend
the search for the support for new Cloud platforms
once you decide to do that.
We have also seen two demos. Illustrating
how to enable GPS tracking and OTA Update
scenarios in AGL using a new AGL service.
Was it funny? At least a little bit right?
That's all from my side. Thank you very much
for your attention.
Any comments and questions are welcome and
can be addressed during the following Q&A
session. Thank you.
