Group 5

Sample Application

Introduction
The application has following components:
1. Model Service
Model manager retrieves configuration files through the user-interface from model
developer and then passes those specifications of the model to the model storage system.
Model manager is also responsible for providing the required model to application
developers from user-interface by retrieving it from the model storage system During
Development of AI Model, the AI Model is developed by the model developer. Here the
model developer builds an AI model and trains it using preprocessed training dataset. Then
this model is uploaded into the platform and the model manager maintains the record using
a model config file and model storage system.

2. Sensor Service
Registers sensor types and sensor instance details in the MongoDB based on
the configuration files.The Message Queue stores the sensors’ data in the message
queue (Kafka Topic) and users can consume the data in these kafka topics.

3. Node Management
We have run the platform on 2 machines connected on LAN. After initialization the
containers will be spawned on these two physical machines by using the inputs from monitoring
service.
This service will periodically check the containers for any failures and respawn the
containers.

How each end user will interact

1. End user
- Sensor UI: This UI will have options to register sensors, and simulate sensor data
streams.

2. Data scientist
- Model UI: This will allow the user to upload an AI model to the platform. This model will
be saved in that user’s repository.
3. Platform Manager:
○ /removeModel: The removeModel command removes the existing model
from the platform.
○ /removeApplication: The removeApplication command removes the
existing application from the platform.
○ /viewModel: The viewModel command allows viewing of existing model
from the platform.
○ /registerSensor: The registerSensor command is used for registration of
sensors on the platform.

4. Model Developer
○ /uploadModel: The uploadmodel command is used by model developers
to upload the model.
○ /removeModel: The removeModel command removes the existing model
from the platform
○ /startModel: The startModel command receives a model as an argument
and starts executing it.
○ /stopModel: The stopModel command stops the currently running model.

5. Application Developer
○ /receiveModel: The receiveModel command retrieves a perfect model
suited for the application from the Model manager and returns it to the
Application manager
○ /uploadApplication: The uploadApplication command is used by
applications developers to upload the application.
○ /receiveData: The application manager can use the receivedata
command to instruct the Sensor Manager to provide sensor data to the
application manager.
○ /predict: The predict command allows the end users to predict the data
using the test dataset present in the application.
○ /downloadDataset: The downloadDataset command downloads the
sensor data from the message queue.
6. End User
○ /login: Users can use the login command to gain access to the platform
or application after authentication.
○ /signup: The signup command allows users to register on the application
and access it.
○ /ifHasData: The end-user will provide data for the application to process.

7. App developer
- Developer UI: This will allow the developer to see lists of available sensors and models
and develop his app using these sensors and models.
 The zip file uploaded by the developer should include configurations about the sensor to
user and models to be used.

Artifact diagram

Model Artifact Diagram:-

In the model config file, the model configurations such as modelID, modelName,i/p and o/p type
and server information will be present.With these information, the application will be able to
access and use the model.

This is the model information running docker and it shows docker container information.

App Config File:-

App config contains information about the type of sensors & model that the application will need.
It needs a mapper service to further connect with required models & sensors.

Sensor Config File :-

Sensor type.json Sensor instance.json

Sensor Config file consists of sensor type & sensor instance. Sensor type stores information
about various types of sensors that are deployed on the platform such as heat, moisture
sensors etc. Sensor instance stores details about particular sensors of each type, there may be
multiple sensors of a given type.

Block diagram
Block Diagram of application

AI Model(s) information used in application

The application will access the different models uploaded in the platform using an API call to the
flask server running in the docker. The server information such as server name, server url and
model information such as input/output type,model ID,etc will be available to the application via
model registry which would store the model information. If model info matches with app
requirements, the necessary API call is made to the model server.

Model informations used:-

i) Server URL
ii) Model input/output type
iii)Docker info

Sensor & controller information

1) Created configuration files for sensor types and sensor instances

● sensor_type.json
● sensor_instance.json

2) Registering sensors into the database (mongodb)

● Take the json files and store sensors in mongo db
 3) Generated dummy data for each sensor instance and stored into kafka topics created for
each instance.
● temp_producer.py : Generates dummy data and store in kafka topic
● light_producer.py: Generate dummy data and store in kafka topic

4) Created a consumer client and provided the following functionalities:

● get_sensor_types(): returns available sensor type ids and their names
● get_sensor_instances(type_id): returns instance id, ip and port of the respective
sensor type id
● consume_data(instance_id): returns data of that particular sensor’s by
consuming from the respective kafka topic

Notification information
The main functionalities of notification and actions is to notify users about specific events.
User requests use case and actions to request manager . Request manager forwards use
case to AI runtime server. Actions which the user has given along with AL runtime server
output stream is given as input to Notification and actions service. Notification and service
take required actions on input received and send responses along with status code to the
user. It gives notification whenever the user's request response is ready. Action service will
take appropriate actions based on the request received from the user.