Introducing 

Prezi AI.

Your new presentation assistant.

Refine, enhance, and tailor your content, source relevant images, and edit visuals quicker than ever before.

Loading…
Transcript

Architecture Design

The Road Ahead

Design Process

Step 1:

Purpose and Requirements

Step 1

Purpose

Class Cognizance is aimed to automate all the necessary administrative actions that are required to be done in educational institutions like schools, colleges, private coaching centres, etc. Administrative actions include

  • Attendance, along with proxy control
  • Updating parents about their child periodically with child’s picture
  • 24x7 direct interaction between parents and teachers regarding the child’s progress via Chat Option in Mobile Application platform.
  • Time-table creation
  • Allotment of classed to teachers
  • Releasing of results online

In the 1st step, the prototype IoT system is being developed, to include only the 1st 3 deliverables as bold above.

The information required to perform the above-highlighted administrative actions would be captured using “Surveillance Camera” units installed in different places within the campus, along with other sensor units as well as using Cloud based Applications and Mobile, Web Applications on external devices.

Behaviour

  • The proposed IoT prototype system detects presence of persons; and initiates reading of data by different types of sensors connected to an Edge device. There are multiple edge devices. The sensors would send real time data via Wi-fi to Cloud Server for storage and processing.
  • The data is stored in Cloud Server and processed via Cloud based Applications to send Student’s Attendance Alert to the parent’s via SMS, Mail and also on Mobile App.
  • The Parent needs to validate Attendance Alert of his/her child to control Proxies and confirm student’s presence in the respective classes.
  • Once the Parent has validated child’s attendance, same gets updated as “Approved” in the Cloud based server under the respective student’s attendance details.
  • The Parent can login via Webpage or Mobile App to check his/ her child’s daily / weekly / monthly attendance report from the cloud server.

System Management Functions

System management functions

The system should provide options

  • for storage and processing of sensor data remotely in cloud.
  • to use the stored data in cloud to send Student’s Attendance Alert to the parent’s via SMS, Mail and also on Mobile App.
  • to validate Attendance Alert to the Parent of his/her child on Mobile App in order to control Proxies and confirm student’s presence in the respective classes (within a time period of 7 days).
  • to check student’s daily / weekly / monthly attendance report from the cloud server via Webpage / Mobile App.

Data analysis Requirement

Data

Analysis Requirement

Data analysis is done in the system on the cloud.

Application Deployment Requirement

Application deployment requirement

  • Cloud based Applications for data storage / processing / analysis.
  • Mobile Application (Android based only for now) to be deployed for parent-teacher interaction, attendance validation.

Security Requirements

Security requirements

  • Personnel specific authentication capability for remote login for student database maintenance and update.
  • Root admin level authentication capability for remote troubleshooting & maintenance, as and when required, in the field.
  • Parents should have user level access to the Mobile App and Web Application login to access child’s (student’s) information.

Step 11:

Process Model Specification

Step 11

Flow-Chart

Step 111:

Domain Model Specification

Step 111

Services

  • IR Sensor detects presence of persons in ROOM (interrupt received) and initiates RFID sensor, and initiates Image Sensor after every specified timer overflow to read data.
  • RFID Sensor to scan ID Card.
  • Image Sensor to capture student image.

Flow-Chart

Step 1v

Step 1v:

Information Model Specification

Flow-Chart

Step v:

Service Specification

Step v

Service 11

Service 1

Service 111

Controller Service

IR Sensor detects presence of persons in ROOM and initiates RFID and Image Sensors to read data.

Service 1

RFID Scan Service

RFID Sensor to scan ID Card.

Image Capture Service

Image Sensor to capture student image.

Step v1:

IOT Level - 4 Specification

Step v1

Flow-Chart

Step v11:

Service Specification

Step v11

Flow-Chart

Step v111

Step v111: Operational View Specification

Device Specification

Device

  • 32-bit Micro-Controller Unit (Node MCU: ESP8266)
  • Sensors
  • IR Sensor
  • RFID Sensor (MFRC522)
  • Image Sensor (comes as part of OV7670 – single-chip VGA camera and image processor in a small footprint package-SCCB (Serial Camera Control Bus) interface).

Communication Protocol

Comm Protocol

  • Physical Layer – Wi-Fi (802.11b/g/n)
  • Link Layer –802.2
  • Network Layer (IPV4/IPV6)
  • Transport –TCP
  • Application - HTTP, MQTT.

API

  • TCP/IP for MQTT Broker.
  • RESTFUL API between Cloud based Applications and external devices’ Applications (like Mobile Apps, Web Apps, etc), implemented with AWS API Gateway

Services

Service 1: CONTROLLER Service: Hosted on device – implemented as embedded C Code, run as a native service.

Service 2: RFID_Scan: Hosted on device – implemented with MQTT.fx Broker.

Service 3: Image_Capture: Hosted on device – implemented with MQTT.fx Broker.

Application

  • Web Application – HTTP Based
  • Application Server - AWS Serverless
  • Database - DynamoDB
  • Analytics – AWS IoT Analytics
  • Observer - External devices like Laptops, Mobile phones, etc (from where webpage / Mobile App can be accessed)

Security

Security

  • Authentication: Web Application, Mobile Application, Database
  • Authorization: Web Application, Mobile Application, Database

Management

Management

  • Application: AWS SAM (Serverless Application Model)
  • Database: AWS Dynamo DB
  • Device: Arduino Device Management

Step 1x

Step 1x:

Device and Component Integration

Device and Component Integration

Integration

  • Node MCU (ESP 8266) is used as Edge Device. Built on Arduino Platform.
  • IR Sensor
  • RFID Sensor (MFRC522)
  • Image Sensor (comes as part of OV7670 – single-chip VGA camera and image processor in a small footprint package-SCCB (Serial Camera Control Bus) interface).

Flow-Chart

Step x:

Application Development

Step x

Development Diagram

Different Applications Proposed

System Architecture

Complete

System Architecture

Methodology

Methodology

&

Modular

Decomposition

“AGILE SCRUM METHODOLOGY” is followed for Software Development of the IoT System.

Test case development is to be done Sprint wise, depending on “Review” upon completion of the earlier completed “Sprints”.

Prototype Development Methodology – AGILE SCRUM METHODOLOGY

Agile Scrum Methodology

Product Backlog is created for the entire SDLC.

Currently, 5 different Sprints are planned for SDLC of the proposed IoT prototype model

  • Cloud Connectivity and Data Processing
  • API Development
  • Website App Development
  • Mobile App Development
  • Hardware Integration and connectivity validation

Product/ Sprint Backlog

Prototype Development Methodology – PRODUCT / SPRINT BACKLOG

Product Backlog (Overall Requirements)

Product Backlog

  • Hardware Integration
  • Wi-Fi Integration
  • RFID Integration
  • IR Sensor Integration
  • Cloud Connectivity and Data Processing
  • Image Data Validation
  • Connectivity to AWS IoT Core via MQTT.
  • Database creation in DynamoDB
  • DynamoDB rule creation in AWS IoT.
  • API Development
  • Link DynamoDB, AWS Lambda Function and AWS API Gateway
  • Website App development
  • Mobile App development

Sprint Backlog

Sprint 1: Cloud Connectivity and Data Processing -Sprint 1 Backlog

  • Image Data Validation
  • Connectivity to AWS IoT Core via MQTT.
  • Database creation in DynamoDB
  • DynamoDB rule creation in AWS IoT.

Sprint 2: API Development - Sprint 2 Backlog

  • Link DynamoDB, AWS Lambda Function and AWS API Gateway

Sprint 3: Website App Development - Sprint 3 Backlog

  • Develop HTTPs based Website App.

Sprint 4: Mobile Application Development - Sprint 4 Backlog

  • Develop Android based Mobile App.

Sprint 5: Hardware Integration and connectivity validation - Sprint 5 Backlog

  • Wi-Fi Integration
  • RFID Integration
  • IR Sensor Integration
  • Node MCU connectivity to AWS IoT Core via MQTT
  • e-2-e connectivity with Node MCU

Sprint 1

Architecture

SPRINT 1 : CLOUD CONNECTIVITY AND DATA PROCESSING

-

ARCHITECTURE

Connectivity to AWS IoT Core via MQTT.

Connectivity to AWS IoT Core via MQTT.

MQTT.fx client is used to publish data to AWS IoT Core (Device Gateway). The data topic can be subscribed in AWS IoT Core as a client; and published payload from MQTT.fx client can be received in AWS IoT.

DynamoDB rule creation in AWS IoT.

DynamoDB rule creation in AWS IoT.

A rule can be created in AWS IoT to perform the action: “Write the subscribed data topic to Dynamo DB”.

SPRINT 1 : CLOUD CONNECTIVITY AND DATA PROCESSING

-

DESIGN

Sprint 1 Design

Connectivity to AWS IoT Core via MQTT.

  • MQTT.fx is a MQTT Client written in Java based on Eclipse Paho MQTT Broker. This is used for secure communication via TLS with AWS IoT.
  • AWS IoT is selected as MQTT Broker for MQTT.fx client.
  • AWS IoT end point used as MQTT Broker address in “MQTT.fx x.x.x” Tool settings. MQTT Broker Port used as 8883, because AWS IoT allows only MQTT with TLS.
  • Security Certificates to be selected from AWS IoT Platform. TLS v1.2 should be selected.
  • A data topic containing JSON Format Payload is published from MQTT client (dummy input from MQTT.fx).
  • The data topic is communicated to the AWS IoT Device Gateway. When data topic is subscribed, the same JSON Format Payload is received in AWS Iot Core, indicating connectivity between MQTT.fx client and AWS IoT Core is working OK.

Connectivity to AWS IoT Core via MQTT.

DynamoDB rule creation in AWS IoT

DynamoDB rule creation in AWS IoT.

  • Create a rule in AWS IoT to insert message into a DynamoDB Table.

  • A data topic containing JSON Format Payload is published from MQTT client (dummy input from MQTT.fx). Shown is the snapshot of the subscribed data topic from AWS IoT Core.

  • The data topic with the respective data payload is also imported to the linked DynamoDB Table via AWS IoT rule.

Sprint 1 Development

SPRINT 1 : CLOUD CONNECTIVITY AND DATA PROCESSING

-

Development

JSON Packet Creation

  • JSON Format Data Payload created for simulation purpose (Date, Time, RFID Tag, etc)

  • JSON Format Data payload created from image file for data simulation purpose (due to absence of hardware)

Json Packet Creation

AWS IOT Core MQTT Setup

  • AWS Account created for use of the different AWS Tools, like AWS IoT Core and Dynamo DB here.
  • AWS Iot Core Certificates are created and stored.
  • MQTT.fx v1.7.1 is installed and configured with MQTT Broker details containing relevant “AWS IoT endpoint” details and “Certificate settings”. Also, TLS v1.2 is selected for security.
  • Connectivity between MQTT.fx client and AWS IoT Device Gateway is verified.

Student DB Table

Student Database Table Creation

  • DynamoDB Table named “StudentDatabase” is created for maintaining Student Database.

  • DynamoDB Table named “StudentDatabase” is populated with student information.

Device Location Info Table

Device Location Table Creation

  • DynamoDB Table named "DeviceLocationInfo" is created for maintaining Device Database.

  • DynamoDB Table named “DeviceLocationInfo” is populated with Device information.

Sensor Data Capture Table

Sensor Data Capture Table

Creation

  • Action created at AWS IoT Core to write the subscribed packet to another DynamoDB Table named “SensorDataCapture”.
  • DynamoDB Table named "SensorData Capture" is created with the above shown schema

Sprint 1 Testing

SPRINT 1 : CLOUD CONNECTIVITY AND DATA PROCESSING

-

Testing

TEST CASE 1: Image File Creation

for simulation purpose (to validate at a later stage that the subscribed image is correctly transmitted).

TEST CASE 1

Image File Creation

Test Steps

  • Download an image file.
  • Convert the image file to Base64 format.
  • Convert the image file from Base64 to HEX format.
  • Convert the image file from HEX Format to JSON Format. (to be used by MQTT.fx client for publishing).
  • Validate, if the JSON Format data payload corresponds to the original image file

Expected Result

Image file converted to JSON Format successfully and corresponds to the original image file.

Actual Result

As expected.

Validation done at this stage by creating a CodeBlock batch file for converting JSON Format data to Image file. At a Later stage during Sprint 2, same would be validated using AWS Lambda function.

TEST CASE 2: Connectivity to AWS IoT Core via MQTT.

TEST CASE

2

Connect to AWS IoT Core via MQTT.

Test Steps

  • Publish several data packets (also JSON format data payload corresponding to image file) to “data topic” from MQTT.fx client.
  • Check if same “data topic” is subscribed by AWS IoT Core.

Expected Result

Data packets published by MQTT.fx client should be received by AWS IoT Device Gateway.

Actual Result

As expected

TEST CASE 3: Database creation in DynamoDB.

TEST CASE

3

Database creation in DynamoDB.

Test Steps

  • Create a DynamoDB Table in AWS Platform.
  • Create Item to add data to the table.
  • Create a backup of the DynamoDB Table for future reference.

Expected Result

  • DynamoDB Table created successfully.
  • Data updated successfully to DynamoDB table.
  • Backup created successfully, upon completion of data update to the table.

Actual Result

  • DynamoDB Table named “StudentDatabase”, “SensorDataCapture”, “DeviceLocationInfo” created successfully.
  • Student data and Device location details updated successfully to DynamoDB table “StudentDatabase” and “DeviceLocationInfo”.
  • Backup created successfully, upon completion of data update to the table “StudentDatabase” and “DeviceLocationInfo”.

TEST CASE 4: DynamoDB rule creation in AWS IoT.

TEST CASE

4

DynamoDB rule creation in AWS IoT.

Test Steps

  • Create a rule in AWS IoT to insert message into DynamoDB Table.
  • Publish data packets from MQTT.fx Client to AWS IoT Core.
  • Check if data subscribed by AWS IoT Core is also copied to the linked AWS DynamoDB Table.

Expected Result

  • Data packets published by MQTT.fx client should be received by AWS IoT Device Gateway.
  • Once the same data topic is subscribed, same data payload can be seen in AWS IoT Core.
  • Also, same data payload corresponding to same data topic in the same order is copied into the linked DynamoDB Table

Actual Result

  • DynamoDB Table named “SensorDataCapture” used in this test case.
  • A rule is defined to insert messages (data payload) into DynamoDB Table "SensorDataCapture".
  • Data payload from the subscribed data topic is successfully and correctly copied into the linked DynamoDB Table “SensorDataCapture”.

Sprint 1 Review

SPRINT 1 : CLOUD CONNECTIVITY AND DATA PROCESSING

-

REVIEW

Status : Done

Status: Done

  • Connectivity to AWS IoT Core via MQTT: Done

  • Database creation in DynamoDB: Done
  • “StudentDatabase” DynamoDB Table created and updated with all required fields successfully; also to be referenced in Sprint 2.
  • “SensorDataCapture” DynamoDB Table created successfully, also to be referenced in Sprint 2.
  • “DeviceLocationInfo” DynamoDB Table created successfully and updated with all required fields successfully, also to be referenced in Sprint 2.

  • DynamoDB rule creation in AWS IoT: Done

Status: Partial Pending

Status:

Partial

Pending

  • Image data validation: Partial Pending
  • This is to be validated using AWS Lambda function during Sprint 2.

Sprint

1

Sprint

11

Updated Sprint Backlog

Prototype Development Methodology – UPDATED SPRINT BACKLOG

(After Sprint 1)

Sprint

111

Sprint

1v

Sprint

v

Sprint 1: Cloud Connectivity and Data Processing -

Backlog

Sprint

1

  • Image Data Validation
  • Connectivity to AWS IoT Core via MQTT.
  • DynamoDB rule creation in AWS IoT.

Sprint 11: API Development -

Backlog

  • Link DynamoDB, AWS Lambda Function and AWS API Gateway
  • Image data validation (appended from previous Sprint)

Sprint 3: Website App Development - Backlog

  • Develop HTTPs based Website App.

Sprint 4: Mobile Application Development - Backlog

  • Develop Android based Mobile App.

Sprint 5: Hardware Integration and connectivity validation -

Backlog

  • Wi-Fi Integration
  • RFID Integration
  • IR Sensor Integration
  • Node MCU connectivity to AWS IoT Core via MQTT
  • e-2-e connectivity with Node MCU

Deployment

Diagram

Deployment Diagram

Deployment Diagram – IN CLASSROOM

Deployment in Class Room

Deployment Diagram – IN SCHOOL BUS

Deployment in Bus

Maintenance Model

Maintenance Model

  • ESP32 +Amazon FreeRTOS
  • Fail Safe Software Upgrade

Final Design

& Progress till Date

Final Design and progress till date

https://drive.google.com/file/d/1W5A5gBgtyjf8Nfz_M-eafBBiXXj10LW-/view?usp=sharing

This Architecture Design Was Presented By

Group 05

Credits

from

Heena Nigam - 2018CIOT530

Arpit Gupta - 2018CIOT540

Debaditya Dasgupta - 2018CIOT505

for

EC-11(Architectural Design)

IoT Capstone Project (IoT_May_2019_C7-2)

PG Diploma IOT - BITS PILANI

Learn more about creating dynamic, engaging presentations with Prezi