Use Case
Smart Car Solution and Sequence
1. Our Philosophy
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?
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
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
18 Jun 2020, 05:19 AM
Table 1: Required files for this tutorial
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
7- Postman APIs Step By Step Guideline
A step by step guideline will be provided here:
[A1-1] → Car 1 GET account info: Getting the information
{{IP_ADDRESS}}:{{PORT}} → this is the localhost where the host runs
[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.
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.
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)
[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)
[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]