Smart-car-use-case

mimik Technology is offering a unique solution to Smart Car use case. Our solution is focused on hybrid utilization of centralized cloud and edge cloud using mimik edge Cloud Engine. We at mimik believe that instead of having all the communications from an end user on the cloud (where it can be any device such as a cellphone or a smart car) to the centralized cloud and back, we can have a hybrid system that leverages potentials of edge cloud engines in order to have a faster, safe, and more suitable solutions to real world problems

2. What is the problem that we want to solve? and how?

In this section we will briefly go over the smart car use case, and the centralized cloud approach versus mimik hybrid approach using edge cloud engine

2-1- Smart Car Use Case Components:

For the sake of better understanding, we simplified the problem and we will describe it using only four components in one system: Car 1, Car 2, Object (a.k.a. obstacle), Smart City Infrastructure (e.g. traffic lights, or an health and safety weather notification system)

2-2-Smart Car Use Case Story

Let’s put the smart car use case into a short story:

A camera on Car 1 is detecting an object/ obstacle (could be anything ranging from a pedestrian to ice) on the road
Car 2 (in close proximity) is approaching from the behind; and Car 1 wants to notify Car 2 on the new situation and presence of an obstacle on the road
Either Car 1 or Car 2 also wants to send a notification to smart city infrastructure (e.g. to traffic light or health and safety weather notification system)

2-3-Centralized Cloud Approach versus mimik Hybrid edgeCloud platform Approach

In conventional solutions for most of the events mentioned in the above story, the end users (smart cars) have to communicate with centralized cloud in order to communicate with each other as well as with the smart infrastructure components. Considering the amount of data generating in smart car use case, and the importance of a fast way of communication to avoid any accidents, and to optimize the transportation system, harnessing the power of mimik hybrid edge cloud engine can be considered as one of the best solution.

mimik hybrid edgeCloud platform is the answer to the following question:

The question is while the Car 1, Car 2, Obstacle, and smart city Infrastructure gateway all are located in close proximity, why all the communications should go a longer way to the centralized cloud?

mimik hybrid edgeCloud engine provides a platform for the end users at the edge to communicate, and transfer data in a secure way without communicating with centralized cloud. That being said, for smart car use case it can provide a platform for a secure, interoperable (between various manufacturers), fast communication between the nodes (a.k.a. end users) on the edge of the cloud. This will lead to lower bandwidth, latency, and more control over data privacy.

3- Smart Car Scenarios and Assumptions

Three scenarios will be covered as part of this training as follows:

3-1- Scenario no.1:

The first car captured/ have an image from the camera and then it can put it on it’s infotainment unit

3-2- Scenario no.2:

The second car can find the first car, then it can view the image generated by the first car (application of mSuperdrive, and mBeam microservices)

3-3- Scenario no.3:

the first car/ or second car will use mIoT microservice to send a notification to smart infrastructure

4- Assumptions

We are not setting up actual cars for this tutorial – We pretend that we have two cars and simulate the data flow using other devices (more details on the tutorial setup will be discussed in the following section)

For the sake of simplicity, we assume that users can use any photos on their devices to be used as a dummy data for the obstacle image

5- Requirements

Before you start to follow the step by step instruction provided on this document, please follow the below steps:

5.1. Edge Cloud Engine:

Download The Edge Cloud Engine and OAuth Tool
Go to Developer Portal and Create your account
Start OAuth Tool, and get your Association and Unassociation account tokens

Note: If you dealt with any difficulties following the above mentioned four (3) steps please check this link for further detailed instruction.

5.2. Postman:

Please download and install the Postman that suits your device.
Please download the collection and the environment provided below in Table 1.
Please import and set the environment variables in Postman
Update association and unassociation tokens in the environment file (the collection and environment files will be provided in the table below)
You can start making queries now

5.3. Hardware Setup:

Device 1 (e.g. a Windows, Linux, macOS, or Raspberry Pi OS device) represents Car 1 in this simulation.
Device 2 (e.g. a Windows, Linux, macOS, or Raspberry Pi OS device) represents Car 2 in this simulation.

6- Postman Collection and Environment At The Glance

If you are already downloaded the postman collection and environment and set them in your Postman, you will see seven (7) folders inside the Final Smart Car Demo postman collection. We will go over them briefly to discuss the expectations from each folder.

[ Group A – Car 1] –> GET and POST ACCOUNT INFO
[ Group A – Car 2] –> GET and POST ACCOUNT INFO
[ Group B – Car 1 ] –> Local Microservice Deployment
[ Group B – Car 2 ] –> Local Microservice Deployment
[ Group C – Car 1] –> mSuperdrive and mBeam API Calls
[ Group D – Car 2] –> mBeam and mSuperdrive
[ Group E] –> mIoT

The first two groups (no.1 & no. 2) are supposed to get the information of each device and do the account association and unassociation. These steps can simply be described as node (or end user) registration and identification.

Group no. 3 and no. 4, will load the required microservices on the edge cloud engine on car 1, and car 2, respectively. These microservices along with the edge cloud engine will make it possible to find other end users in the proximity or in the same Wi-Fi network, to view the image captured by car 1 on car 2, and to send notification to smart infrastructure Group no. 5 APIs will help mostly with the scenario no. 1, as discussed in section 3. Group no. 6 APIs will help mostly with the scenario no. 2, as discussed in section 3. Group no. 7 APIs will help mostly with the scenario no. 3, as discussed in section 3.

7- Postman APIs Step By Step Guideline

A step by step guideline will be provided here:

1. [ Group A – Car 1] –> GET and POST ACCOUNT INFO

[A1-1] → Car 1 GET account info: Getting the information

{{IP_ADDRESS}}:{{PORT}} → this is the localhost where the host runs

accountId → this is the account information

name → this is the device name

nodeId → device id

[A2-1] → Associate Account: Please make this API call. As you already registered and logged in on Developer Portal, following the steps provided in section 5 of this tutorial the response will tell you that this is already associated (please make sure that your account is associated and edge Cloud Engine is running on both devices)

[A3-1] → Unassociate Account: Please make this API call ONLY if you would like to unassociate your account (otherwise please skip this step in order to move forward with the next API calls). In case if you want to unassociate your account make sure that the unassociation token has been already set in your Postman environment.

2. [ Group A – Car 2] –> GET and POST ACCOUNT INFO

Basically all the APIs in this group would work in the exact same way as the APIs in group 1, with only difference is that they are getting information and do the account association for Car 2.

3. [ Group B – Car 1 ] –> Local Microservice Deployment

Once we open the application it loads the microservices on the edge Cloud Engine

[B1-1] → Car 1 Deploy mBeam Microservice Image

Please download the mBeam microservice image (as a microservice image example) from Table 1 provided in this tutorial

Once you downloaded the microservice image you can deploy the mBeam image. Again by checking the time it takes to perform this call we can understand how fast these API calls are

To deploy the microservice image of your choice, in [B1-1] please click on “Body” as your payload and select the image file as the VALUE. The KEY will be “image”, and the VALUE will be the image file (e.g. mbeam-v1.tar – similar to the below image)

[B2-1] → Car 1 Deploy mSuperdrive Microservice Image

Please follow the same procedure as [B1-1] to deploy mSuperdrive microservice image (Please use the mSuperdrive microservice image provided in Table 1)

[B3-1] → Car 1 Deploy mIoT Microservice Image

Please follow the same procedure as [B1-1] to deploy mIoT microservice image (Please use the mIoT microservice image provided in Table 1)

[B4-1] → GET Microservice Images from mCM: Upon making the [B1-1], [B2-1], and [B3-1] API calls, mBeam, mSuperdrive, and mIoT microservices images will be deployed. You can get the associated images from mCM using [B4-1]. Also by clicking on Time label on top right corner of the response display you can check how long it takes to receive a response from this API call.

It is of note that the time it takes for a single operation (any of the API calls) is not an independent parameter and actually depends to many other parameters (e.g. hardware and network capabilities, number of other software that are running on the system, and so forth). Even though this is the case, it will still provide valuable data on generally how the mimik backend service functions and how different API calls on the same system will result in different values.

[B5-1] → Car 1 Deploy mBeam Microservices to mCM Container

Now you can deploy the microservices to the mCM container. The same procedure will apply for the following two APIs as well:

[B6-1] → Car 1 Deploy mSuperdrive Microservice to mCM Container
[B7-1] → Car 1 Deploy mIoT Microservice to mCM Container

[B8-1] → Car 1 GET Microservice Containers from mCM

By making this API call you can get the microservice containers from mCM

[B9-1] → DELETE Microservice Containers from mCM

Please make this API call in case you want to delete a microservice container from mCM (This is not part of this tutorial, but we encourage you to follow this step once you feel comfortable with this tutorial upon completion)

[B10-1] → DELETE Microservice mCM image

Please make this API call in case you want to delete a microservice mCM image (This is not part of this tutorial, but we encourage you to follow this step once you feel comfortable with this tutorial upon completion)

4. [ Group B – Car 2 ] –> Local Microservice Deployment Basically all the APIs in this group would work in the exact same way as the APIs in group 3, with only difference is that they are deploying microservices and images locally for Car 2 as represents by device no. 2.

5. [ Group C – Car 1] –> mSuperdrive and mBeam API Calls APIs in this group will mostly support the scenario no. 1, as discussed in section 3

[C1] → mSuperdrive LOCAL DISCOVERY Please make the C1 API call in order to see the Link Local clustering example. But what is Link Local clustering? “Link Local clustering is finding other edge nodes (a.k.a. end users) on the same local network (e.g. Wi-Fi) and form a cluster via utilizing mimik Edge Cloud Engine“ To shed a light on what exactly C1 does, let’s assume that you have started edge cloud engine and associated your account on two of your devices (e.g. a laptop and a cellphone) on the same local network (e.g. your home or office Wi-Fi), by making the C1 API call, you will find both of your devices in the response object. Also you can check the time it takes for this API call to get the respond back and form a link local cluster and later compare it with the time it will take to form a nearby cluster (e.g. E1) with devices not existing on a same local network but within close proximity.

[C2] → mSuperdrive mimik add a media Obj locally (Car 1)

For the sake of simplification, and as discussed in above sections, you can assume that any image of your choice on your local machine is actually taken from the obstacle by the Car 1 camera, and can be used as a dummy data for this purpose.

Using C2 API call, we actually add the image locally on Car 1 itself. Please use the image file path of your choice as the url. Please check the Body object in the below image for more clarification.

[C3] → Check the mimiked file locally

By making C3 API call you can check the mimiked file locally (and yes! mimiked is a verb, we mimik people use, when we use mSuperdrive microservice to POST or GET an object)

[C4] → mbeam NODE1 GET play_queue Let’s first discuss what is mBeam? “mBeam is a mimik open source edge microservice that provides Restful APIs for streaming content among edge nodes.“ Due to wide range of applications, mBeam microservice can be utilized in various types of applications. Please click here if you are interested to learn more on it’s application in a media streaming example. By clicking on C4, you can get the list of files in mBeam play_queue

[C5] → delete mbeam (id) Node 1

Please only make this API call in case you want to delete an item from play_queue (This is not part of this tutorial session).

[C6] → mSuperdrive mimik add a media Obj to Car 2

This API call is very similar to [C2] except for the fact that the intention is not to add a media Object locally but to add it to Car 2 (We already found Car 1 through making [C1]).

6. [ Group D – Car 2] –> mBeam and mSuperdrive

APIs in this group will mostly support the scenario no. 2, as discussed in section 3

[D1] mbeam NODE2 GET play_queue

Similar to [C4], you can get the list of files in mBeam play_queue on Car 2.

[D2] mbeam NODE2 DELETE (id)

Please only make this API call in case you want to delete an item from play_queue (This is not part of this tutorial session).

[D3] mbeam NODE2 GET play_queue {id}

Get an item by ID from the play queue on Car 2.

[D4] Check the mimiked file

Very Similar to [C3].

[D5] mSuperdrive GET nodes/{id}

Given a node ID, check for reachability/presence of the node

7. [ Group E] –> mIoT

Group no. 7 APIs will support mostly the scenario no. 3, in which either Car 1 or Car 2 wants to send a notification to the smart city infrastructure. The purpose of making [E1] and [E2] API calls are basically to find other Internet of Things (IoT) devices and clustered them either by proximity [E1], or by being in the same network [E2].

Later by making [E3] API call Car 2 can send a notification, and by making [E4] the sensor data can be recieved.

[E1] findIoTDevices cluster by nearby

It will find Internet of Things (IoT) devices clustered by proximity.

[E2] findIoTDevices cluster by network

It will find Internet of Things (IoT) devices clustered by being in the same network.

[E3] POST notifyIoTDevices

To upload a sensor data or a notification. Please see an example below:

[E4] GET notifyIoTDevices

By making this API call you can retrieve the data just posted by [E3]

1. Our Philosophy

2. What is the problem that we want to solve? and how?

3. Smart Car Scenarios and Assumptions

4. Assumptions

5. Requirements

6. Postman Collection and Environment At The Glance

7. Postman API’s Step By Step Guidline

Social